Reconfigurable,hierarchical component-based architecture &amp; framework and methods for rapidly developing sensor device-enabling software applications

ABSTRACT

A reconfigurable, hierarchical component-based architecture and framework for rapidly developing sensor device enabling software applications can have a rule-based data structuring system, a series table system, and a system of acquiring data from a data provider. User defined relationships can be established to enable exchange of data between the rule-based data structuring system, the series table system, the system of acquiring data, another rule-based data structuring system, an object oriented wrapping system, a data filtering system, a data structure grouping and merging system, a data device writer system, and a network communications system. Each system can have components and subcomponents by which the user defined relationships can be established, for example by embedding components of various systems within the rule-based data structuring system, and/or other systems, and/or by setting a property value to link components of the systems with a component of the rule-based data structuring system and/or other systems.

BACKGROUND

The present invention relates to systems, methods, and computer programsfor a reconfigurable, hierarchical component-based architecture andframework for rapid development of sensor device-enabling softwareapplications.

Sensors are vital components in a vast array of security, automotive,industrial, medical, commercial, as well as consumer products. Sensorsare integral to the functionality, performance, and distinctiveness ofan expanding array of established and emerging industries andapplications, including automotive, process control, consumerelectronics and office and industrial automation products, machinerymonitoring, air and ground transportation, environmental monitoring,HVAC/building automation, home appliances, medical devices andequipment, aerospace, security, and wireless monitoring systems. Sensorsare a key enabling technology that continues to find opportunities toallow for achieving new and promising, potentially higivolumeapplications; for example, automotive stability control, rolloverdetection, cabin air quality monitoring, occupancy detection, tirepressure monitoring; handheld devices (including mobile phones, personaldigital assistants, tablet computers, global positioning system-equippeddevices); and expanded sensor networks in industrial, commercial orhomeland security applications.

The future of the sensors lies with wireless sensor networks andcomplex, multi-sensor systems. Wireless sensors (i.e., sensors thattransmit and/or receive data without using a physical wire connection)have highly realistic growth opportunities in diverse applications thatrequire sensor networks that are cost-effective and easy to install,deploy, and reconfigure. Moreover, the continually evolving wirelesscommunications protocols standards continue to help drive the expansionof more economical sensor networks. It is expected that networkedwireless sensors will increasingly gain a real foothold in themarketplace and generate significant revenue, as standard wirelesscommunication protocols and data structures that support a wide range ofapplications become geared toward optimizing sensor networks.

Companies that design and integrate systems that incorporate sensorstend to provide custom-design methodologies and solutions for specificsensor applications. Such customized processing solutions can result inhigh cost and are often not readily transferable to other applications.The present invention remedies this problem by optimizing sensor design,processing, and implementation and provides a design-time and run-timetool set that can enable developers of all experience to readily createsensor-based applications.

It is widely accepted that the future of sensor network and systemapplication development lies within spearheading the design,development, and commercialization of an economical, modular, powerful,plug-and-play sensor processing system.

Thus, in the fragmented and application-specific sensor marketplace,there is a need for a smart sensing and flexible solution, such as aReconfigurable, Hierarchical Component-Based Architecture & Frameworkand Methods for Rapidly Developing Sensor Device-Enabling SoftwareApplications, to enable a wide variety of sensors to have plug-and-playcapability across a wide range of applications which will providesignificant value to sensor element manufacturers and designers as wellas developers and users of sensor-based systems. Such capabilities cangreatly expand the served applications for sensors and sensor-basedproducts.

SUMMARY

A Reconfigurable, Hierarchical Component-Based Architecture & Frameworkand Methods for Rapidly Developing Sensor Device-Enabling SoftwareApplications as described herein generally comprises a sensor-basedapplication toolset, which features design-time and run-time components,that allows software developers and engineers to rapidly develop anddeploy diverse sensor-based software applications and systems. Thesystems and methods described herein can be utilized on an end-usercomputer for or with enterprise, visualization, and other displaytechnologies, as well as on servers, at-point with sensors or sensornetworks, or with other distributed computing processors. Although themethod and systems described herein are particularly applicable tosensor-based data, other types of device data could be utilized.

The methods and systems described are both sensor and database agnostic,which means data can be incorporated from a litany of sensor types andinformation supplied to a variety of database and file structures.Different sensor types include, for example, electro-optic sensors(still, video, panoramic), individual environmental and conditionmonitoring sensors, wireless sensors, wireless sensor networks, andradio-frequency identification (RFID) tags. The databases that can bepowered by the systems and methods described herein include, forexample, Microsoft SQL Server, Oracle, MySQL, Microsoft Access, Exceland others. This allows for a variety of sensors, sensor aggregatortechnologies, databases, and visualization applications to be utilizedwith the systems and methods described herein.

The Reconfigurable, Hierarchical Component-Based Architecture &Framework and Methods for Rapidly Developing Sensor Device-EnablingSoftware Applications can reduce the costs associated with developmentof sensor, or other device, based applications, integrate multiple typesof sensors into a sensor-based application, providing quality assurancefor any software application, reconfigure a new application any time anew sensor is added to the system, and update or change the application.Moreover, the associated systems and methods described herein allow foroptimal utilization of all sensors in a sensor based system/application.These systems and methods also allow developers and engineers to use theprogramming language and programming environment of their choice,thereby reducing the learning curve associated with learning newsoftware.

An embodiment of a Reconfigurable, Hierarchical Component-BasedArchitecture & Framework and Methods for Rapidly Developing SensorDevice-Enabling Software Applications can generally comprise arule-based data structuring system having a series component and anassociated field subcomponent; a series table system having a seriestable component; and a system of acquiring data from a data provider,wherein the data preferably includes some portion of sensor data Therule-based data structuring system can be configured by user-definedrelationships to exchange data with at least one of another rule-baseddata structuring system, the system of acquiring data, the series tablesystem, an object oriented wrapping system having at least one of acommand component and an associated parameter subcomponent, and a datafiltering system having at least one of a filter component and anassociated condition subcomponent Furthermore, the user-definedrelationships can established by embedding components of such listedsystems within the rule-based data structuring system and/or by settinga single property value to link components of the various listed systemswith the series component of the rule-based data structuring system. Theuser defined relationships can be established using provided design-time(visual) or programmatic interfaces.

The field, parameter and condition subcomponents can also beuser-defined, and the relationship can be similarly established, such asby embedding the subcomponent in the rule based data structuring systemor linking it thereto, such as via an associated component of thesubcomponent, which associated component must be embedded in, or linkedto a component of, the rule based data structuring system.

The rule-based data structuring system can also be configured accordingto the user-defined relationships to exchange data with one or more of:a data structure grouping and merging system having a sensor groupcomponent, an associated group series subcomponent, an associatedexisting field subcomponent, and an associated trigger subcomponent; adata device writer system having an associated device writer component;and a network communications system having a data sending componentand/or a data receiving component.

The group series, existing field and/or trigger subcomponents can eachbe user-defined, and can likewise be embedded,o r linked to, anassociated component to establish the user defined relationships. Theuser defined relationships can also be established among other systems,including the system of acquiring data, the series table system, theobject oriented wrapping system, the data filtering system, the datastructure grouping and merging system, the data device writer system,and the network communications, such that data can be exchanged amongthe various systems as well as with the rule-based data structuringsystem.

An embodiment of the reconfigurable hierarchical component basedarchitecture and framework as described above can further comprise oneor more central device component, each of which can be comprised of oneor more of the rule-based data structuring system, the system ofacquiring data, the series table system, the object oriented wrappingsystem, the data filtering system, the data structure grouping andmerging system, the data device writer system, and the networkcommunications system. The central device component thus comprises alogical sensor, i.e., a logical representation of a sensor, or likedevice, which can also generally be referred to as a data provider.Multiple instances of the central device component, which can representmultiple data providers, can be created and each can be usable at thesame time.

An embodiment of a method for rapidly developing sensor device-enablingsoftware applications can generally comprise defining a rule-based datastructuring system having a series component and a field subcomponent;defining a series table system having a series table component;receiving sensor data into the rule-based data structuring system;defining relationships to exchange data between the rule-based datastructuring system and one or more of another rule-based datastructuring system; the system of acquiring data; the series tablesystem; an object oriented wrapping system having a command componentand a parameter subcomponent; and a data filtering system having afilter component and a condition subcomponent.

The method of establishing user defined relationships can be compriseembedding components of such listed systems within the rule-based datastructuring system and/or setting a single property value to linkcomponents of such listed systems with the series component of therule-based data structuring system.

The field, parameter and condition subcomponents can also beuser-defined, and the relationship can be similarly established, such asby embedding the subcomponent in the rule based data structuring systemor linking it thereto, such as via an associated component of thesubcomponent, which associated component must be embedded in, or linkedto a component of, the rule based data structuring system.

The method can further comprise defining relationships to exchange databetween the rule-based data structuring system and one or more of: adata structure grouping and merging system having a sensor groupcomponent, a group series subcomponent, an existing field subcomponent,and/or a trigger subcomponent; a data device writer system having adevice writer component; and a network communications system having adata sending component and/or a data receiving component. Therelationships can be user defined, and can be established as describedabove, e.g., by embedding components of the systems within therule-based data structuring system and/or setting a single propertyvalue to link components of the systems with the series component of therule-based data structuring system.

The field, parameter and condition subcomponents can also beuser-defined, and the relationship can be established as describedpreviously, such as by being embedded, or linked in combination with arespective associated component, in which the respective component(associated with the subcomponent) must itself be embedded, or linked toa component of the rule based data structuring system.

Embodiments of the method can further comprise defining relationships toexchange data among other systems, such as: the system of acquiringdata, the series table system, the object oriented wrapping system, thedata filtering system, the data structure grouping and merging system,the data device writer system, and the network communications system.Methods for establishing user defined relationships therebetween can beas described above, e.g., by embedding components of such listed systemswithin the rule-based data structuring system and/or by setting a singleproperty value to link components of such listed systems with the seriescomponent of the rule-based data structuring system.

Further embodiments of the method can comprise representing one or moreof the rule-based data structuring system, the system of acquiring data,the series table system, the object oriented wrapping system, the datafiltering system, the data structure grouping and merging system, thedata device writer system, and the network communications system as acentral device component Multiple instances of central device componentscan be created wherein each is a logical representation of a device,such as a sensor or like device, which provides data to be processed bythe method. A plurality of instances of the central device componentscan each be used at the same time.

In general, functions which can be performed according to certainembodiments of systems and methods associated with a Reconfigurable,Hierarchical Component-Based Architecture & Framework and Methods forRapidly Developing Sensor Device-Enabling Software Applications asdescribed herein can further comprise, for example, one or more of thefollowing:

-   -   Automatically wrapping third party SDKs and APIs from both        managed and unmanaged dynamic link libraries (DLLs);    -   Eliminating the need for aliasing like function names by storing        the dynamic link library (DLLs) wrapping calls in separate        assemblies within memory;    -   Performing behind-the-scenes data type conversions;    -   Performing rule-based data structuring;    -   Automatically building custom data structures based off of        existing data structures;    -   Performing rule-based data filtering;    -   Providing for data logging and database insertion in various        formats;    -   Automatically creating database(s), tables, fields, and rows in        various database and file formats;    -   Performing event-driven data merging of different specified data        structures;    -   Logically grouping various data structures, so that they can be        treated as one logical data structure;    -   Performing the merging of different data structures by using        common primary keys;    -   Building custom data structures using the designer interface,        including the ability to append custom data fields;    -   Allowing direct data binding to common integrated development        environment (IDE) controls;    -   Empowering event catching that allows for the retrieval or        modification of values, before or after the fact;    -   Automatically populating data structures based on events (such        as another data structure being populated or a command being        executed);    -   Calling wrapped function calls for a group of data structures        with a single command;    -   Performing low-level data fusion;    -   Being particularly useful for applications that use complex data        sets (systems that have heterogeneous sensors);    -   Enabling cloning and serialization of existing sensor components        (including there corresponding data structure schema);    -   Establishing a relationship link between different data        structure and another data structure, or between a data        structure and a return value and/or parameter value of a wrapped        function;    -   Transferring data between different data structures using        network communication protocols including TCP/IP and UDP        supporting IPv4, IPv6, and other standards;    -   Providing visual, object-oriented, drag-and-drop design-time        components that allow for the custom definition of incoming        data;    -   Providing run-time components that allow for the definition of        incoming data;    -   Providing a single-click/single entry design-time component        interface to define the various data structures (sensors) and        its corresponding subcomponents;    -   Automatically generating code in common object oriented        programming languages based upon the defined design-time        components and subcomponents;    -   Providing the framework and functionality for utilization of        sensor and non-sensor data including security convergence;    -   Reducing the time to market of a software application;    -   Integrating seamlessly into Integrated Development Environments        (IDEs);    -   Providing complete help system and API documentation that        seamlessly integrates with the existing help systems of IDEs;        and,    -   Providing developers a means to rapidly develop sensor network        applications by automatically/dynamically generating the object        oriented code that is defined in the provided components.

To the accomplishment of the foregoing and related ends, certainillustrative aspects of the present invention are described herein inconnection with the following description and the associated drawingfigures. These aspects are indicative of but some of the various ways inwhich the principles of the present invention may be employed, and thepresent invention is intended to include all such aspects and theirequivalents. Other advantages and novel features of the presentinvention may become apparent from the following detailed description ofthe present invention when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The features and advantages of the present invention will become moreapparent from the detailed description, set forth below, when taken inconjunction with the drawings in which:

FIG. 1 is a block diagram illustrating a system architecture of anembodiment of a reconfigurable, hierarchical component-basedarchitecture and framework for rapid development of sensordevice-enabling software applications, showing the data flow of sensordevice data from a sensor device to the end user software application.

FIG. 2 is a block diagram illustrating the software architecture of anembodiment of a reconfigurable, hierarchical component-basedarchitecture and framework for rapid development of sensordevice-enabling software applications, showing communication among thevarious components of an embodiment of the system of FIG. 1.

FIG. 3 is a block diagram illustrating the various components andsubcomponents and the interaction between an Object-Oriented WrappingSystem that may be executed by the embodiment shown in FIG. 2.

FIG. 4 is a block diagram illustrating the various components andsubcomponents and the interaction between the Rule-Based (User-Defined)Data Structuring System that may be executed by the embodiment shown inFIG. 2.

FIG. 5 is a block diagram illustrating the various components andsubcomponents and the interaction between the Data Structure FilteringSystem that may be executed by the embodiment shown in FIG. 2.

FIG. 6 is a block diagram illustrating the various components and theinteraction between the Data Structure Grouping and Merging System thatmay be executed by the embodiment shown in FIG. 2.

FIG. 7 is a block diagram illustrating the component and methods and theinteraction between the Series Table System that may be executed by theembodiment shown in FIG. 2.

FIG. 8 is a block diagram illustrating the component and methods and theinteraction between the Data Device Writer System that may be executedby the embodiment shown in FIG. 2.

FIG. 9 is a block diagram illustrating the component and methods and theinteraction between the Network Communication System that may beexecuted by the embodiment shown in FIG. 2.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

The present invention is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. Additionally, the left-most digit of a reference numberidentifies the drawing in which the reference number first appears.

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the Reconfigurable, Hierarchical Component-BasedArchitecture & Framework and Methods for Rapidly Developing SensorDevice-Enabling Software Applications. For convenience, theReconfigurable, Hierarchical Component-Based Architecture & Frameworkand Methods for Rapidly Developing Sensor Device-Enabling SoftwareApplications will be referred to hereinafter simply as “the presentinvention,” but it is to be understood that all such referenceshereinafter to “the present invention” are intended to embrace anyalterations, modifications and variations of the present invention thatfall within the spirit and scope of the associated claims.

It may become apparent to one skilled in the art that the presentinvention may be practiced without these specific details. In otherinstances, well-known structures and devices may be shown in blockdiagram form in order to facilitate description of the presentinvention.

Overview

The present invention is a sensor-based application toolset, whichfeatures design-time and run-time components, that allows softwaredevelopers and engineers to rapidly develop and deploy diversesensor-based software applications and systems. The present inventioncan be utilized on an end-user computer for or with enterprise,visualization, and other display technologies, as well as on servers,at-point with sensors or sensor networks, or with other distributedcomputing processors.

The present invention is both sensor and database agnostic, which meansthat it can incorporate data from a litany of sensor types and supplyinformation to a variety of database and file structures. Among thesensor types are electro-optic sensors (still, video, panoramic),individual environmental and condition monitoring sensors, wirelesssensors, wireless sensor networks, and radio-frequency identification(RFID) tags. Among the databases that can be powered by the systems andmethods described herein are Microsoft SQL Server, Oracle, MySQL,Microsoft Access, Excel and others. This allows for a variety ofsensors, sensor aggregator technologies, databases, and visualizationapplications to be utilized along with the present invention.

The present invention reduces the costs associated with development ofsensor-based applications, integrating multiple types of sensors into asensor-based application, providing quality assurance for any softwareapplication, reconfiguring a new application any time a new sensor isadded to the system, and updating or changing the application. Moreover,the present invention allows for optimal utilization of all sensors inthe sensor based system/application. Further, the present inventionallows developers and engineers to use the programming language andprogramming environment of their choice, thereby reducing the learningcurve associated with learning new software.

In general, functions which can be performed according to certainembodiments of systems and methods associated with a Reconfigurable,Hierarchical Component-Based Architecture & Framework and Methods forRapidly Developing Sensor Device-Enabling Software Applications asdescribed herein can further comprise, for example, one or more of thefollowing:

-   -   Automatically wrapping third party SDKs and APIs from both        managed and unmanaged dynamic link libraries (DLLs);    -   Eliminating the need for aliasing like function names by storing        the dynamic link library (DLLs) wrapping calls in separate        assemblies within memory;    -   Performing behind-the-scenes data type conversions;    -   Performing rule-based data structuring;    -   Automatically building custom data structures based off of        existing data structures;    -   Performing rule-based data filtering;    -   Providing for data logging and database insertion in various        formats;    -   Automatically creating database(s), tables, fields, and rows in        various database and file formats;    -   Performing event-driven data merging of different specified data        structures;    -   Logically grouping various data structures, so that they can be        treated as one logical data structure;    -   Performing the merging of different data structures by using        common primary keys;    -   Building custom data structures using the designer interface,        including the ability to append custom data fields;    -   Allowing direct data binding to common integrated development        environment (IDE) controls;    -   Empowering event catching that allows for the retrieval or        modification of values, before or after the fact;    -   Automatically populating data structures based on events (such        as another data structure being populated or a command being        executed);    -   Calling wrapped function calls for a group of data structures        with a single command;    -   Performing low-level data fusion;    -   Being particularly useful for applications that use complex data        sets (systems that have heterogeneous sensors);    -   Enabling cloning and serialization of existing sensor components        (including there corresponding data structure schema);    -   Establishing a relationship link between different data        structure and another data structure, or between a data        structure and a return value and/or parameter value of a wrapped        function;    -   Transferring data between different data structures using        network communication protocols including TCP/IP and UDP        supporting IPv4, IPv6, and other standards;    -   Providing visual, object-oriented, drag-and-drop design-time        components that allow for the custom definition of incoming        data;    -   Providing run-time components that allow for the definition of        incoming data;    -   Providing a single-click/single entry design-time component        interface to define the various data structures (sensors) and        its corresponding subcomponents;    -   Automatically generating code in common object oriented        programming languages based upon the defined design-time        components and subcomponents;    -   Providing the framework and functionality for utilization of        sensor and non-sensor data including security convergence;    -   Reducing the time to market of a software application;    -   Integrating seamlessly into Integrated Development Environments        (IDEs);    -   Providing complete help system and API documentation that        seamlessly integrates with the existing help systems of IDEs;        and,    -   Providing developers a means to rapidly develop sensor network        applications by automatically/dynamically generating the object        oriented code that is defined in the provided components.

System Architecture Overview

Referring to FIG. 1, a block diagram illustrating the data flow ofsensor device data among various processing stages from the actualsensor device to the end-user software application interface is shown.It should be understood that the particular architecture and framework103, shown in FIG. 1 is for illustrative purposes only and does notlimit the present invention. Other implementations for performing thefunctions described herein will be apparent to persons skilled in therelevant art(s) based on the teaching contained herein, and the presentinvention is directed to such other implementations.

FIG. 1 illustrates means by which raw sensor device data is processedinto useful decision making information, in the context in which anexemplary embodiment is applied. The Sensor and Sensor Networks region101 of the diagram illustrate the capturing and transmission of rawsensor data, or data which includes sensor data. Although the presentinvention is particularly applicable to processing sensor data, it is tobe understood that other types of data could also be processed.

The Intermediate Processing region 102 illustrates the low-levelfunctions, i.e., via third party software development kits (SDKs) andapplication program interfaces (APIs), that take place in order totransmit the raw sensor data into decrypted, configured data that can bereceived into an Integrated Development Environment (IDE). The Reusable,Reconfigurable Component-Based Architecture and Framework region 103illustrates an embodiment of an architecture and framework 103 residingwithin an IDE that enables communication, management, structuring,filtering, fusion, and exportation of raw sensor data. The architectureand framework 103 enables developers to rapidly develop sensor-enablingapplications by providing a modular, flexible architecture where varioussystem, components, and methods interact to produce customized,reconfigurable applications. The End-User Software Application Interfaceregion 104 illustrates an application of the sensor data acquiredthrough the architecture and framework 103 to produce an end-usergraphical interface to interpret the raw sensor data into usefuldecision making information.

General System Operation

Referring to FIG. 2, this block diagram illustrates an embodiment of acentral device component 202 and the various systems, and theinteraction between the various systems within an embodiment of thereusable, reconfigurable component-based architecture and frameworkregion 103 of FIG. 1. These systems include but are not limited to, acentral device component 202, an object-oriented wrapping system 203, arule-based data structuring system 204, a data structure grouping andmerging system 205, a data filtering system 206, a series table system207, a data device writer system 208, as well as a networkcommunications system 209.

Collectively, the component-based architecture and framework systems,permit a developer or engineer to wrap third party software developmentkits (SDKs) and application program interfaces (APIs), create customdata structures for the sensor device data, and perform various actionson the custom data structures, such as filtering structures, groupingstructures, merging structures, data sourcing and data binding tostructures, automatic database and file creation and insertion ofstructures, as well as exportation of data structures. More details onthe structure of the delineated data processing systems are providedhereinafter in connection with the description of FIG. 3(Object-Oriented Wrapping System), FIG. 4 (Rule-Based Data StructuringSystem), FIG. 5 (Data Structure Grouping and Merging System), FIG. 6(Data filtering system), FIG. 7 (Series Table System), FIG. 8 (DataDevice Writer System), and FIG. 9 (Network Communications System).

The hierarchical, reconfigurable component-based architecture andframework 103 provides a developer or engineer with an architecture andframework written in a common object-oriented programming language thatenables the rapid development of a software application layer by using asuite of components that defined interactions between system componentsand subcomponents. The architecture and framework provides anobject-oriented design component toolset for providing object templatederivation tools for accessing and editing a set of based objecttemplates. This permits developers of applications to reuse andreconfigure components in a modular fashion.

The architecture and framework 103 implements a reusable softwarecomponent encapsulating functionality which allows multiple instances ofthe component and/or subcomponent to be used at the same time. Thearchitecture provides a both a design-time and programming interface,also referred to as a programmatic interface. The design-time interfaceprovides the developer with an extensive, graphical environment thatenables single-click and single entry definition of components andsubcomponents.

The architecture and framework 103 automatically generatesobject-oriented code in the developer's environment, based upon thedesign-time and/or programmatic component and subcomponent definitionsas defined by the developer. The architecture and framework 103 enablesdevelopers to communicate with third party sensors and then process thedata into customized data structures via a plurality of components andsubcomponents. Each system within the architecture and framework 103 cancontain components and subcomponents, and employ methods, that allow theuser to acquire raw sensor data and manage that data in a variety ofways, as to allow the developer to develop a front-end for the end userin rapid way in an object-oriented programming language of their choice.This allows users to communicate with various sensors from differentmanufacturers and different SDKs and APIs and then to format andstructure that data in such a way as to allow them to append customfields, create custom data structures, export data structures,automatically insert custom data structures into a database and createthe database, base a data structure off of another data structure, basea data structure off of a parameter and/or a return value of a wrappedfunction, merge custom data structures, group data structures, andprovide data sourcing and binding to common IDE controls.

An exemplary embodiment of a reconfigurable hierarchical component basedarchitecture and framework 103 for rapidly developing sensor deviceenabling software applications can comprise a rule based 204 datastructuring system having at least one of a series component 401 and anassociated field subcomponent 402; a series table system 207 having aseries table component 701; and a system of acquiring data from a dataprovider. The architecture and framework 103 is particularly usefulwhere the data contains at least some portion of sensor data. he rulebased 204 data structuring system can be configured by user-definedrelationships to exchange data with one or more of another rule based204 data structuring system, the system of acquiring data, the seriestable system 207, an object oriented wrapping system 203 having acommand component 301 and/or associated parameter subcomponent 302, anda data filtering system 205 having a filter component 601 and/or anassociated condition subcomponent 602. The user-defined relationshipscan established by embedding components of such listed systems withinthe rule based 204 data structuring system and/or by setting a singleproperty value to link components of such listed systems with the seriescomponent 401 of the rule based 204 data structuring system. Forexample, a link can be established by making a selection whichassociates the command component 301 of the object oriented wrappingsystem 203 with the series component 401 of the rule based datastructuring system 204. Afterwards, there can be additional user-definedrelationships established by similarly setting additional propertyvalues, but the initial setting established the overall relationship.

The associated subcomponents, e.g, the aforesaid field, parameter andcondition subcomponents 602, are user-defined and are similarly embeddedand/or linked in combination with a respective associated componentthereof to establish the user defined relationships.

The rule based 204 data structuring system can further be similarlyconfigured according to the user-defined relationships to exchange datawith one or more of a data structure grouping and merging system 205having a sensor group component 501, an associated group seriessubcomponent 502, an associated existing field subcomponent 504 402,and/or an associated trigger subcomponent 503; a data device writersystem 208 having an associated device writer component 801; and anetwork communications system 209 having a data sending component 901and/or a data receiving component 902. The group series, existing field,and trigger subcomponents 503 can be user-defined and can be embedded orlinked, as described above, in combination with a respective associatedcomponent thereof to establish the user defined relationships. The userdefined relationships can also be established among other systems inaddition to just with the rule based data structuring systems 204.

The architecture and framework 103 provides data management and dataaggregation for sensor devices. The architecture and framework 103enables creation of one or more central device components 202, each ofwhich acts as a logical sensor device or sensor device(s). In otherwords, each central device component is a logical representation of oneor more sensors, or like devices. The central device component 202 canprovide instructions to embed sub-components, use a programminginterface, use a visual, design-time interface, and/or a data-bindinginterface. The central device component 202 can contains systems,components, and subcomponents, and employ methods, that seamlesslyintegrate into the architecture and framework 103 to allow for thesensor device data acquisition and management. A plurality of centraldevice components 203 can be used at the same time in order tocommunicate and manage any number of sensor devices within thearchitecture and framework.

The central device component 202 enables developers to acquire, manage,and structure data for any given sensor in their application. Thecentral device component 202 provides device management by providing a“container” for the various systems, collection of components, andcollection of subcomponents needed to interact on behalf of a logicalsensor. In an exemplary embodiment, the central device component 202represents a sensor in a sensor network. As an example, in order toincorporate a sensor into an application, multiple matters need to beaddressed so that the sensor can be incorporated in a highly customizedapplication, including but not limited to:

-   -   communication and interaction with the sensor by utilizing        functionality to allow direct insertion into data structuring        systems and by automatically generating code to wrap and invoke        unmanaged code and utilizing resulting values and parameters as        data;    -   structuring of incoming “packetized”, raw sensor data by        determining defined and undefined structured data rules and        ‘splitting’ and converting data into respective manageable        sections;    -   storing the incoming sensor data;    -   processing of the sensor data into relevant values by breaking        down the “packets” of information;    -   filtering of the incoming sensor data by comparing incoming        processed and unprocessed data against defined filters and        conditions;    -   automatically exporting of the sensor data to storage mediums by        utilizing functionality to build a multitude of datastore        structures using a minimal number of defined parameters then        organizing and/or converting the sensor data and inserting it        into the data store;    -   fusing of the sensor data to provide intelligent, processed data        by creating in memory storage structures and combining data        based off of a minimal number of selected rules;    -   customizing the sensor data structure (i.e. add fields, store        only relevant portions of a data structure); and,    -   communicating of the sensor data to other devices/applications        by utilizing functionality to construct standardized and/or        customized network communication protocols.

As a way to address the many obstacles of incorporating sensors into anapplication, the central device component 202 manages all of the varioussystems that are needed in order to fully integrate a sensor into anapplication. The central device component 202 does this by providingcollections of components and subcomponents that define the exponentialinteractions that need to take place in order to incorporate a sensorinto an application in the desired manner of the application developer.The central device component 202 houses all of the systems, components,and subcomponents for a particular sensor that a developer would wantincorporated into an application. Basically, the central devicecomponent 202 houses all of systems, components, and subcomponents, andemploys the methods defined in the systems in FIGS. 3 through 9, for aparticular sensor in an application.

In addition, the central device component 202 is capable of utilizingsensor data and non-sensor data from a multitude of other data sourcesincluding datastores, web services, and network data.

The architecture and framework 103 allow developers to copy and pastcentral device components 202 in design-time, and provides cloningfunctionality for run-time to allow for the quick deployment and rapiddevelopment of many like sensor devices. The cloning functionality ofthe central device component 202 enables creation of a shallow copy of alogical sensor, including all defined components, subcomponents, andrelationships, but without the accompanying data that is associated withthe central device component 202 being cloned.

Event subscription to certain actions within the architecture andframework 103 can be subscribed to by any system component orsubcomponent within the application, to allow the developer dynamicflexibility when creating a graphical user interface for the sensordevice(s). The architecture and framework 103 inherits basic componentbase classes, whereby the architecture and framework 103 can takeadvantage of previously developed software in a component base classexisting within the internal framework of the IDE in which thearchitecture and framework 103 resides, to ensure interfacecompatibility.

An exemplary embodiment of the reconfigurable hierarchical componentbased architecture and framework 103 can comprise one or more centraldevice components 202, each having one or more of the rule based 204data structuring system, the system of acquiring data, the series tablesystem 207, the object oriented wrapping system 203, the data filteringsystem 205, the data structure grouping and merging system 205, the datadevice writer system 208, and the network communications system 209.Each central device component 202 is basically a logical representationof one or more data providers, e.g., sensors. Multiple instances of thecentral device components 202 can be created, and each can be used atthe same time.

The reconfigurable hierarchical component based architecture andframework 103 can further comprise an object oriented design componenttoolset having object template derivation tools for accessing andediting a set of based object templates, such that the toolset utilizesinheritance of basic operational capability from a component base classexisting within an internal framework of an IDE in which thereconfigurable hierarchical component based architecture and framework103 resides. The toolset can enable establishment of the user-definedrelationships between systems which comprise the central devicecomponent 202. The central device component 202 can include a visualrepresentation thereof, a design-time interface to access the visualrepresentation, a programmatic interface, and a data-binding interface.The aforementioned user-defined relationships can be established bysetting the single property value via at least one of the design-timeinterfaces and the programmatic interfaces. Setting the single propertyvalue to link the series component 401 with other components of systemsto be related to the rule base data structuring system can also includesetting additional property values for the associated subcomponents ofthe components, and embedding components can also include embeddingassociated subcomponents of the components.

The design time interface can provide an extensive graphical environmentfor establishing the user-defined relationships via the setting a singleproperty value. However, establishing the user defined relationships,such as setting property values and/or embedding component and/orassociated subcomponents, can be performed one or more of theprogrammatic interface, and the design-time interface. The programmatic,design-time, and data binding interfaces can be separate interfaces.

One or more central device components 202 can also be saved as asoftware application program, wherein the software application programcomprises common object-oriented code, and wherein the softwareapplication program is rapidly developed using a suite of the componentsand subcomponents of the aforesaid systems which employ the user-definedrelationships that establish the exchange of data therebetween. Thesoftware application can be saved on a computer readable medium asinstructions for causing one or more computer systems to emulate thesaved central device component 202(s). As mentioned above, the basicoperational capability of the systems, or components thereof, can beinherited from existing component base classes within the internalframework of and IDE in which such systems reside, such that thecomponents the components inherit respective characteristics andproperties from the existing component base classes to ensure interfacecompatibility by taking advantage of previously developed software.

Referring now to FIG. 3, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a object-oriented wrapping system 203 within an embodimentof the architecture and framework 103 of FIG. 1. The object-orientedwrapper system 203 allows developers to simplify the writing of enablingsensor device drivers from both managed and unmanaged dynamic linklibraries. The wrappers of the dynamic link libraries are stored inseparate assemblies within memory which eliminates the need for aliasinglike DLL functions. The term “functions” as used herein, in relation toDLLs, is inclusive of subroutines. The object-oriented wrapping system203 allows developers to provide default parameter values for thewrapped functions. The object-oriented wrapping system 203 allows forreturn values and wrapped function parameter values to be modified andrelated to data structuring components and subcomponents. This enablesdevelopers to automatically populate the series table system 207 withthese related values when a command component 301 associated with awrapped function is invoked. The object-oriented wrapping system 203permits developers to invoke the command components 301 from the user'sobject-oriented integrated development environment. The object-orientedwrapping system 203 enables developers to perform callbacks of thecommand component 301 using delegate functionality, which allowscallbacks to be initiated in various defined areas of an application.

The object-oriented wrapping system 203 can include a command component301 and a parameter subcomponent 302. A plurality of command components301 and parameter subcomponents 302 is permitted within an embodiment ofthe architecture and framework 202. Each wrapped function is assigned acommand component 301, and each command component 301 can have anassociated return value, unless the wrapped function is a subroutine, inwhich case there would be no return value. There can be multipleparameter subcomponents 302 associated with a command component 301, andeach parameter subcomponent 302 can correspond to a wrapped functionparameter value. The command component 301 enables developers to wrapthird party SDKs and APIs. The command component 301 allows developersto specify the original equipment manufacturer command (e.g. function)name, the original equipment manufacturer file name (e.g. the thirdparty SDK—in the file format of a .dll), the return data type (returnvalue), an alias for the command component 301, and a plurality ofparameter subcomponents 302 to define the parameters of the wrappedfunction. The parameter component 302 enables developers to define thespecific parameter values that are needed in order to invoke the wrappedfunction. The command component 301 allows developers to specify theparameter data type, the parameter name, whether the parameter is beingpassed “by reference” or “by value”, a default value, and whether or notthe parameter is optional.

Various command components 301, and within in each command component301—various parameter subcomponents 302—can be specified for aparticular central device component 202. The object-oriented wrappingsystem 203 enables the developers to customize and define, to theirliking, a number of command components 301 and parameter subcomponents302 in order to be able to pull in sensor device data from multiplesensor devices, including heterogenous sensor devices. Theobject-oriented wrapping system 203 automatically generates the codeneeded to wrap each language in run-time and stores each wrappedfunction in a separate assembly within memory which eliminates the needfor aliasing like function calls between different command components301.

The object-oriented wrapping system 203 provides automated wrappingfunctionality that allows the application to read data from, and pushout data to, a particular central device component 202. Theobject-oriented wrapping system 203 can provide this functionality basedoff of (upon) various simple, single-click properties that the developer(user) defines.

As an example, assume a sensor is collecting data and the applicationneeds to read the sensor's data and break it down and store it intocustom data structures so that the sensor can be incorporated into theIDE for application programming. In an exemplary embodiment, based uponvarious user-defined properties in the command component 301 andaccompanying parameter subcomponent(s) 302, the object-oriented wrappingsystem 203 automatically wraps the specified function that is needed tocommunicate with the sensor so that the sensor and data can beincorporated into the IDE for application programming. Theobject-oriented wrapping system 203 would automatically generate thecode necessary to wrap a function call based off of the definedproperties in the command component 301 and parameter subcomponent(s)302 and would then construct and compile the code during run-time withina separate assembly within memory. The object-oriented wrapping system203 would then convert any default values that are specified by thedeveloper, convert any structures to byte arrays (if needed), and theninvoke the function based on any number of specified parameters.

After the function is executed, various events are raised that can besubscribed to by the developer or by other components within theapplication. After the function is executed the object-oriented wrappingsystem 203 checks to see if there are series components 401 (andcorrelating field subcomponents 402) in the rule-based data structuringsystem that are related to the particular command component 301 (andcorrelating parameter subcomponents 302) being invoked. If there is arelated series component 401 in the rule-based data structuring system204, then the object-oriented wrapping system 203 automaticallycommunicates the incoming data transferred to the application (theincoming data is a result of invoking the wrapped function call) intothe rule-based data structuring system 204 for further processing. Theobject-oriented wrapping system 203 enables developers to initiate thisfunctionality by defining a few properties and writing a single line ofcode in their application.

In an exemplary embodiment, the object-oriented wrapping system cancomprise a means (object oriented code) for automatically generatingobject-oriented class wrappers of DLL functions to simplify writing ofdevice enabling programs from at least one of managed and unmanagedDLLs; means (object oriented code) for modifying wrapped functions ofthe DLLs; and means (object oriented code) for relating the wrappedfunctions to at least the rule based 204 data structuring system inaccord with the user-defined relationships to exchange data. Thisenables the series table data system to be automatically populated withthe desired data. The code required to wrap the language for each of thewrapped functions can be automatically generated in run-time.

Each wrapped function can be assigned a command component 301, typicallyonly one command component 301 for each wrapped function, and a returnvalue is typically associated with the command function, unless thefunction is a subroutine, in which case there is no return value. In thecontext of this description, the term “function” encompassessubroutines. One or more parameter subcomponents 302 can also associatedwith the command component 301, each of which corresponds to a wrappedfunction parameter value. The wrapped function parameters, or parametervalues, is a user defined value for the wrapped function.

The means for modifying the wrapped can include modifying the returnvalue and/or the wrapped function parameter values, the means forrelating the wrapped functions can include establishing the user-definedrelationships between the command component 301 of the object orientedwrapping system 203 and the series component 401 of the rule based datastructuring system 204.

Establishing the user-defined relationship can further comprise settingthe single property value to link the series component 401 with thecommand component 301, which results in the field subcomponent 402becoming linked to any parameter subcomponent 302(s) associated with thecommand component 301, and also to any wrapped function parameter valuesassociated with the parameter subcomponents 302. Linking the seriescomponent 401 with the command component 301 also links the fieldsubcomponent 402 with the return value typically associated with thecommand component 301.

In an exemplary embodiment, relationships can be established between theobject oriented wrapping system 203 and the rule based data structuringsystem 204 via a return value of a command component 301 (or wrappedfunction), and/or via a parameter subcomponent 302 (or wrapped functionparameter value). The wrapped function parameter values associated withthe parameter subcomponents 302 can be changed/modified by invoking thewrapped function. Stated another way, the wrapped function parametervalues are the values for the parameter subcomponents 302 that arechanged as a result of invoking the wrapped function (i.e. invoking thecommand component 301 and associated parameter subcomponents 302). Usersdo not have to specify a default value (but can if they choose to), auser must, however, specify wrapped function parameter values (via theparameter subcomponent) that are required to run a wrapped function.

Referring to FIG. 4, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a rule-based (user-defined) data structuring system 204within an embodiment of the architecture and framework 103 of FIG. 1.The rule-based data structuring system 204 allows developers to definecustom data structures in order to allow them to manipulate, organize,and fuse data in such a way as to make it useful, in the context ofproviding an end-user software application. Once a data structure isdefined for a central device component 103, then that data can befiltered, grouped, merged, stored, and even be inserted automaticallyinto a dynamically created custom data structure. The rule-based datastructuring system 204 allows developers to define any number of customdata structures for a particular central device component. Therule-based data structuring system 204 can include a series component401 and field subcomponents 402 which define the manner in which sensordevice data will be managed and allocated within the series table system207 for a particular central device component 103. The rule-based datastructuring system 204 provides developers with event-driven functionsthat allow the developer to programmatically invoke various datastructuring functions programmatically.

The rule-based data structuring system 204 permits developers to relatea series component 401 to any command component 301 or another seriescomponent 401 within the same central device component 103. Therule-based data structuring system 204 permits developers to relate afield subcomponent 402 to any parameter subcomponent value, returnvalue, or with another field subcomponent 402 within the same centraldevice component 103. The rule-based data structuring system 204 permitsdevelopers to define and append custom data fields (i.e. unique IDs,timestamps, etc.) to a series component's 401 related series tablecomponent 701 of the series table system 207 (described hereinafter inconnection with the description of FIG. 7).

A plurality of series components 401 and field subcomponents 402 arepermitted within an embodiment of the architecture and framework 103.The series component 401 enables developers to define custom datastructures for a particular central device component 103. In oneembodiment, a series component 401 could contain one or more fieldsubcomponents 402. Multiple series components 401 can be defined for aparticular central device component 103. Series components 401 act asthe template for a related series table component 701, and the fieldsubcomponents 402 act as a template for data columns within the relatedseries table component 701. When incoming sensor device data isreceived, the rule-based data structuring system 204 allows developersto define the way in which that data will be broken out via the seriescomponents 401 and field subcomponents 204. The actual incoming sensordevice data will be inserted into the defined custom data structure viaseries table system 207.

The rule-based data structuring system 204 provides a method to allowdevelopers to customize a base template for incoming device data so thatthe when device data is being read from a sensor device it will populaterows of data into the related series table system 207 using the defineddata structure (i.e. series component 401).

The series component 401 allows developers to specify a maximum amountof rows the related series table component 701 (contained in the seriestable system 207) can allow. A maximum row handler is provided todevelopers to enable them to specify what is to happen to the data inthe related series table component 701 in the event the maximum rowsallowed is reached. The rule-based data structuring system 204 allowsdevelopers to specify a plurality of series components 401 (e.g. tables)for a particular central device component 103 and a plurality of fieldsubcomponents 402 to define the fields (e.g. columns) of a particularseries component 401 (e.g. table). The series component 401 allowsdevelopers to apply filters to incoming sensor device data via the datafiltering system 206. The series component 401 enables developers toestablish a relationship to a specific command component 301 or anotherseries component 401 within the same central device component 103.

The field subcomponent 402 allows developers to define the field (e.g.column) data type and whether or not the field (column) is a primary key(used in the data structure grouping and merging system 205, describedhereinafter in connection with FIG. 5). The field subcomponent 402allows developers to specify a relationship to either a specific commandparameter subcomponent 302 or to another field subcomponent 402 withinthe same central component device 203, or a custom value. The fieldsubcomponent 402 allows developers to specify what parts of the incomingdevice data will be used to populate the defined column in the relatedseries table component 701 (within the series table system 207).

Various series components 401, and within in each series component204—various field subcomponents 402—can be specified for a singlecentral device component 103. The rule-based data structuring system 204enables the developers to customize and define multiple data structuresthrough series components 401 and field subcomponents 402. Therule-based data structuring system 204 automatically generates the codeneeded to manage, organize, and specify what and how data will bepopulated into the series table component 701 that is related to aparticular series component 401.

The rule-based data structuring system 204 provides custom datastructuring capabilities by allowing a user of the present invention todefine various properties about the way in which sensor data for aparticular sensor, or data provider, is stored, including but notlimited to, what incoming data is to be stored, how incoming data isstored, the way in which incoming sensor data is structured when beingstored, what type of data is stored, and what relationship links areestablished in order to create efficient storage methods. The rule-baseddata structuring system 204 can directly interact with the datafiltering system 206 via the filter components and conditionsubcomponents (described hereinafter in connection with FIG. 6).

As an example, assume a sensor is collecting data and the applicationhas to read the sensor's data, break it down, and store it into customdata structures so that the sensor can be incorporated into the IDE forapplication programming. In an exemplary embodiment, a command component301 (and its corresponding parameter subcomponents 302) invokes a readfunction on the sensor. The object-oriented wrapping system 203 checksto see if any series components 401 (and its corresponding fieldsubcomponents 402) are related to the command component 301. The datastructuring system 204 receives notification that a series component 401within the same central device 202 component is related to the commandcomponent 301 that just invoked the read function. The data structuringsystem 204 can build a row of data based upon setting a single (userdefined) property value, such as by a simple, single-click, and createsthe row schema for its related series table component 701 based upon itscorresponding field subcomponents 402. The row schema is created byadding multiple series table fields together to form a row of data thatcorresponds with each specified data type for every specified fieldsubcomponent 402 within the related series component(s) 401.Additionally the series component 401 would then cause to be appendedany additional specified custom fields to the row schema.

Once the schema is created, the data structuring system 204 defines theway in which the data being transmitted from the object-orientedwrapping system 203 will be broken down. The data structuring system 204then acquires the transmitted data from the related command component301, performs automatic data type conversions, breaks down the data intothe various field formats that will be entered into the related seriestable component 701, and then checks the data filtering system 206 todetermine if the incoming data is to be filtered. Once the actual sensordata is processed it is sent to an internal series table component 701to be stored. The data structuring system 204 then checks to see if anyother series components 401 (and any corresponding field subcomponents402) within the data structuring system 401 are related to it, and then,if related, the process repeats itself Therefore, based off of one readfunction being performed, the object-oriented system 203 and the datastructuring system 204 automatically identify a relationship and thenautomatically break-down, format, and then populate sensor data into aseries table component 701. The data structuring system 204 thusprovides virtually unlimited options to define custom data structuresand relationships.

In the rule based 204 data structuring system, the series component 401and/or field subcomponent 402 can define a custom data structure for oneor more sensors, or data providers, associated therewith. The seriescomponent 401 and/or field subcomponent 402 can define the manner inwhich data from the associated data providers will be formatted in theseries table system 207. The rule based data structuring system 204 caninclude one or more of a means (object oriented code) for sending datafrom one rule based 204 data structuring system to another rule based204 data structuring system and a means (object oriented code) forreceiving data in one rule based 204 data structuring system sent fromanother rule based 204 data structuring system.

The custom data structures can be defined based upon return valuesand/or the wrapped function parameter value. Custom data structures canbe created based upon a previously created custom data structure, andcan also be created from previously created data structure, but withadditional fields appended thereto. For example, the custom datastructure can be created based upon a previously created custom datastructure, with additional fields appended thereto, wherein theadditional field is created based upon return values and/or wrappedfunction parameter values.

Additionally, events can be fired and subscribed to by subscribing onesof at least one of the series component 401 and the field subcomponent402, with which the aforesaid user-defined relationships can beestablished to associate these components/subcomponents with the commandcomponent 301 and parameter subcomponents 302 of the object orientedwrapping system 203. This results in establishing relationship linksbetween the associated return values and/or wrapped function parametervalues and the custom data structure. Consequently, user-definedrelationships can be established between a multiple custom datastructures simply by establishing user-defined relationships between therule based data structuring systems 204.

The series component 401 and the field subcomponent 402 can thus berepresented as logical components of one ore more data providers havingone or more associated/defined custom data structure. The seriescomponent 401 and/or the field subcomponent 402 can be cloned and/orserialized for run-time copy & paste functionality of the custom datastructures. Copy & paste functionality of the custom data structures canalso be provided in design-time.

Referring to FIG. 5, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a data structure grouping and merging system 205 within anembodiment of the architecture and framework 202 of FIG. 2. The datastructure grouping and merging system 205 allows developers to definenew custom data structures from existing (previously defined) datastructures in order to allow developers to manipulate, organize, andfuse/merge data in such a way as to make it useful, in the context ofproviding an end-user software application. The data structure groupingand merging system 205 allows developers to group various existing fieldsubcomponents 504 within different central device components 203 into asensor group component 501. A sensor group component 501 can contain asingle group series subcomponent 501 (which acts in a similar manner asthe series component 401 in the rule-based data structuring system 401).The data structure grouping and merging system 205 enables developers toadd multiple, existing field subcomponents 504 from different centraldevice components 203 for the purpose of performing event-driven merging(via a simple group), and bulk data merging (via a bulk group).

The data structure grouping and merging system 205 provides filteringcapabilities on data (via the data filtering system 206) the same way asthe data filtering system 206 filtering is applied to a series component401 of the rule based data structuring system 204. Basically, the datastructure grouping and merging system 205 creates a group seriessubcomponent 501 that is comprised of multiple existing fieldsubcomponents 504. The data structure grouping and merging system 205enables developers to group data from multiple sensor devices into oneseries table component 701 (within the series table system 207,described hereinafter in connection with FIG. 7). The data structuregrouping and merging system 205 is defined by adding any number ofexisting field subcomponents 504 to a specific sensor group component501 and then by specifying the type (e.g. purpose) of the group. Thedata structure grouping and merging system 205 allows developers toinvoke a particular command component 302 for all of the central devicecomponents 203 included in the sensor group component 501 (in order fora central device component 202 to be included into a sensor groupcomponent 501, a central device component 202 has to have at least oneof it's field subcomponents 402 included into the sensor group component501).

The data structure grouping and merging system 205 is comprised of thesensor group component 501, the group series subcomponent 501, and atrigger subcomponent 503. Each sensor group component 501 can contain asingle group series subcomponent 501 (which acts just like a seriescomponent 401 in the rule-based data structuring system 401). A sensorgroup component 501 allows the developer to define the type of thesensor group component 501 (i.e. a bulk group or a simple group). Aplurality of sensor group components 501 can be used within anapplication. The group series subcomponent 501 allows developers tospecify a maximum row setting for the group series' related series tablecomponent 701, and how to handle the event of the maximum row settingbeing reached. Filter components 601 and condition subcomponents 602 canbe applied to the group series subcomponent 501 in the same manner inwhich they are applied to series components 401 in the rule-based datastructuring system 401.

The data structure grouping and merging system 205 allows developers tomerge data from the existing field subcomponents 504 included in thegroup series subcomponent 501. The data structure grouping and mergingsystem 205 allows developers to define when to add a row of data to thegroup series subcomponent's related series table component 701 based offof trigger subcomponents 503. The sensor group component 501 enablesdevelopers to define a plurality of trigger subcomponents 503 that allowthe developer to define when a row is to be added to the group seriessubcomponent's related series table component 701 (i.e. when aparticular series component's related series table component 701 gets arow of incoming device data). The trigger subcomponent 503 allowsdevelopers to define when to add rows of data to the group series'related series table component 701 by specifying an included seriescomponent 401 which will act as the trigger for adding rows (in orderfor a series component 401 to be included into the sensor groupcomponent 501, a series component 401 has to have at least one of itsfield subcomponents 402 included into the sensor group component'sexisting field subcomponents 504). The trigger subcomponent 503 allowsdevelopers to define the event in which a row should be added (i.e. aseries component's related series table component 701 gets a new row ofdata, therefore add a row of data to the group series subcomponent'srelated series table component 701).

The data structure grouping and merging system 205 allows developers toinvoke a bulk merge method that will merge the included existing fieldsubcomponents 504 based off a primary key. Therefore, for each seriescomponent 401 that is included in the sensor group component 501 atleast one of it's existing field subcomponents 504 must have a primarykey that is used to merge the data from the included existing fieldsubcomponents 504 (in order for a series component 401 to be includedinto a sensor group component 501, a series component 401 has to have atleast one of it's field subcomponents 402 included into the sensor groupcomponent's existing field subcomponents 504).

Basically, the data structure grouping and merging system 205 allowsdevelopers to obtain portions of various data structures found withinthe application into a single, unified data structure. The datastructure and grouping system 205 fuses data from various predefinedcustom data structures based upon various events specified by thedeveloper, or based upon developer-invoked merging functions. The datastructure and grouping system 205 provides data fusing capabilities bydefining what portions of data structures are used to comprise thegrouped data structure, communicating with the included central devicecomponents in the application, and catching events from the includedcentral device components (via the trigger subcomponents) that specifywhen to add a row of data to the group series subcomponent's 502 relatedseries table component 701.

As an example, assume there are three sensors collecting and sendingdata to the application. The reading of the sensor data is invoked bythe object-oriented wrapping system 203, and then passed on to the datastructuring system 204 for structuring and processing, and then storedwithin the series table system 207. Each of the sensors may send severaldifferent types of data (i.e. temperature, picture, GPS coordinates,etc.). The developer may want to retrieve the current temperature valuesfor each sensor every time any one of the sensors get a row added theirseries table component 701 and store them in a single, unified seriestable component 701. In an exemplary embodiment, the developer could addthe corresponding temperature existing field subcomponents 504 to thesensor group component 501. Once the desired existing fieldsubcomponents 504 (i.e. temperature readings) are added to the sensorgroup component 501, the data grouping and merging system 206automatically includes the central device components 202 and seriescomponents 401 that correspond with the included existing fieldsubcomponents 504. The sensor group component 501 can then automaticallysubscribe to various events that correspond with the included fieldsubcomponents 402 via the trigger subcomponents 503. Developer-definedtrigger subcomponents 503 specify that when a row of data is added tothe included existing field subcomponent's 504 related series tablecomponent 701, that a row of data needs to be added to the sensor groupcomponent's 501 group series subcomponent's 502 related series tablecomponent 701. A row of data is added to an included existing fieldsubcomponent's 504 related series table component 701, and then thesensor group component 501 checks to see if there is a triggersubcomponent 503 that corresponds with the series component 401 thatjust received a row of data.

The trigger subcomponents 503 notifies the group series subcomponent 502that an included existing field subcomponent 504 just received a row ofdata, and therefore the group series subcomponent 502 must to structurea row of data for insertion into the group series subcomponent's 502related series table component 701. The group series subcomponent 502automatically obtains the current values of the included existing fieldsubcomponents 504 and structures a row of data to be inserted based offof the existing field subcomponents 504 defined structures (defined inthe data structuring system 204). The group series subcomponent 502 thenchecks to see if any filters components 601 are defined for the groupseries subcomponent 502. If there any filter components 601 then thestructure data row will be sent to the data filtering system 206 forfiltering, then it will be sent the series table system 207 forinsertion into the related series table component 701.

The previous example describes just one aspect of the data structuregrouping and merging system 205. The data structure grouping and mergingsystem 205 can also perform developer-invoked bulk merge functions thattake the including existing field subcomponents 504 and determine theprimary keys defined and merge the various existing field subcomponent504 data based upon a primary key(s). This is particularly useful formerging data from various sensors in the application based upon aprimary key, such as a date/time. In addition the data structuregrouping and merging system 206 can run command components 301 for allthe central device components 202 included in the sensor group component501. The sensor group component 501 houses all of the various componentsand defines the interactions between all of the components in the datastructure grouping and merging system 205.

In an exemplary embodiment, the data structure grouping and mergingsystem 205 can include a sensor group component 501, group seriescomponent 401, and/or an existing field subcomponent 504 402, whichdefine a merged data structure comprised of at least a portion of one ormore custom data structures previously defined by the rule based datastructuring system 204. As used herein, the term “merged” can be usedinterchangeably with the terms “grouped” and “fused” in regard to customdata structures defined by the data structure grouping and mergingsystem 205. One or more of the sensor group component 501, group seriescomponent 401, and existing field subcomponent 504 402 can define themanner in which the merged data structure is formatted in the seriestable system 207.

In an exemplary embodiment, the user-defined relationships areestablished between the sensor group component 501 and the seriescomponent 401 of the rule based data structuring system 204 to definethe merged data structure. Additionally, establishing the user-definedrelationships can include embedding the field subcomponent 402 of therule based data structuring system 204 in the existing fieldsubcomponent 504 402 of the data structure merging and grouping system.The merged data structures can also be defined based upon an eventsubscription by subscribing ones of the series component 401 and/orfield subcomponent 402 of the rule based data structuring system 204. Insuch an embodiment, the data structure grouping and merging system 205can include a trigger subcomponent 503 associated with the group sensorcomponent. In an exemplary embodiment, the trigger subcomponent 503 canbe associated with a series component 401 or the sensor group component501, and the group series subcomponent 502 can have a user-definedrelationship established with the rule based 204 data structuring systemvia at least the subscribing series component 401, such that definingthe merged data structure based upon events can be enabled.

The merged data structures can be defined based upon common primarykeys, and the grouping of multiple the merged data structures can bebased upon group function calls.

Referring to FIG. 6, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a data filtering system 206 within an embodiment of thearchitecture and framework 103 of FIG. 1. The data filtering system 206allows developers to filter incoming sensor device data from beingtransmitted to the series table system 207 for a particular seriescomponent 401. The data filtering system 206 allows developers to filterincoming data using a plurality of filters (via the filter components601) and a plurality of conditions (via the condition subcomponents 602)for a particular filter component 601. The data filtering system 206allows developers to establish multiple “or-ing” filter conditions (i.e.if x or x then filter the incoming data) via the filter component 601,and it allow developers to establish for multiple “and-ing” filterconditions (i.e. if x and x then filter the incoming data) via thecondition subcomponent 602. The data filtering system 206 allowsdevelopers to define custom filters based upon common conditionaloperators (i.e. <, >, =, etc.) and bitwise operators (i.e. And-ing,NAnd-ing, and Masking).

The data filtering system 206 can include a filter component 601 and acondition subcomponent 602. A plurality of filter components 601 andcondition subcomponents 602 are permitted within an embodiment of thearchitecture and framework 202. The filter component 601 enablesdevelopers to establish a plurality of condition subcomponents 602 forthe particular filter component 601, and whether or not the filtercomponent 601 is enabled. Each individual filter component 601 istreated as an “or-ing” operation, meaning that if any one of a number offilter component's are met, then the data will be filtered. In contrastthe condition subcomponent 602 is treated as an “and-ing” operation,meaning that if all of the condition subcomponents for a particularfilter component 601 are met then the data will be filtered Thecondition subcomponent 602 enables developers to define a specificfiltering condition for a particular filter component 601. Theconditions subcomponent 602 allows developers to specify what data fieldis being filtered, what the condition operation is (i.e. =, <,>, etc.),whether or not to apply a not operation (i.e. if not x =6 then filterdata), and the value the field being filtered is compared against (auser-defined value or the value of a particular field). The conditionsubcomponent 602 allows developers to filter data related to fieldsubcomponents 402 that have a data type of “byte” through user-definedbitwise operations (i.e. And-ing, NAnd-ing, and Masking). Various filtercomponents 601, and within each filter component 601—various conditionsubcomponents 602—can be specified for a single series component 401.The data filtering system 206 enables developers to customize filters toregulate the incoming sensor device data for a particular seriescomponent 401 and its related series table component 701.

The data filtering system 206 provides filtering capabilities for sensordata that is associated with a series component 401 and its relatedseries table component 701. In addition, the data filtering system 206is capable of filtering sensor data and non-sensor data from a multitudeof other data sources including datastores, web services, and networkdata. The data filtering system 206 can work in direct conjunction withthe data structuring system 204 and/or the data structure grouping andmerging system 205 via the series component 401 and/or the group seriessubcomponent 502. Any number of filters can be defined for a particularseries component 401/group series subcomponent 502. The data filteringsystem 206 filters incoming series component 401 data after it entersthe data structuring system 204/data structure grouping and mergingsystem 205, but before it actually gets stored in the series 401/groupseries subcomponent's 502 related series table component 701.

As an example, assume a sensor is collecting data and the application isinvoking read functions to obtain the data to the application via theobject-oriented wrapping system 203. The sensor data is sent to relateddata structuring system 204 for eventual insertion into the series tablesystem 701. Before the data is actually stored in the series tablesystem 207, the data structuring system 204 checks to see if there areany filters associated with the series component 401 that the sensordata is associated with. In an exemplary embodiment, a series component401 has just received notification from a related command component 301,and data is being sent to the data structuring system 204 forprocessing. Once the data is processed and structured, the datastructuring system 204 checks to see if there is any filter components601 defined for the series component 401. The data filtering system 206receives notification that an incoming series component's 401 data has afilter(s) defined in order minimize the storage of redundant informationinto the series table system 207. The data filtering system 206 receivesthe structured data row (structured via the data structuring system 204)before it gets sent to the series table system 207 to be stored in aseries table component 701. The data filtering system 206 loops throughall the filter components 601 associated with the series component 401.The data filtering system 206 then loops through all of the conditionsubcomponents 602 associated with a particular filter component 601.Each condition subcomponent 602 is a user-defined expression that isapplied to a field value in the structured data row. The conditionsubcomponent 602 evaluates the specified expression by performing acommon operation (e.g. if field value (1) is greater than or equal to17).

The data filtering system 206 automatically provides only the filteringcondition operations that are applicable to the particular field valuebeing filtered (i.e. if the data type for the field value is byte', thenthe data filtering system 206 only provides And-ing, NAnd-ing and equalsconditional operators). Based upon the user-defined conditionsubcomponent 602, the data filtering system 206 evaluates the expressionand determines if it is ‘True’ or ‘False’. If the condition subcomponent602 is found to be ‘False’ then the remaining condition subcomponents602 associated with the filter component 601 will be ignored, and thenext filter component 601, if any, is evaluated. If the conditionsubcomponent 602 is found to be ‘True’, then the next conditionsubcomponent 602, if any, is evaluated. If all of the conditionsubcomponents 602 are found to be ‘True’ for a filter component 601,then the filter component 601 is found to be ‘True’, and the structureddata row is filtered (i.e. not sent to the series table system forstorage). In the case of multiple filter components 601 being associatedwith a series component 401, only one of the filter components 601 needsto be found ‘True’ in order for the structured data row to be filtered.The data filtering system 206 applies to group series subcomponents 502in the same manner as the series components 401. The data filteringsystem 206 provides an unlimited amount of ways to define variousfilters that can apply to a structured data row provided by the datastructuring system 204. The data filtering system 206 allows developersto detect any number of anomalies, detect threats and abnormal readings,and eliminate the data overload problems that are common to sensor-basedapplications.

In an exemplary embodiment, the data filtering system 205 can include auser defined expression to filter data, and the data to be filtered canbe defined by user defined relationships established between the datafiltering system 205 and one or more of the rule based data structuringsystem 204 and the data structure grouping and merging system 205. Theuser-defined expression can be a user-defined bitwise operational filtercondition and/or a common conditional operator. The bitwise operationalfilter condition can be one or more of And-ing, NAnd-ing, and Masking.The common conditional operators can be one or more of <, >, =,contains, left-most contains, and right-most contains. Additionally, NOToperations can be applied to the common conditional operators.

In an exemplary embodiment, the user defined relationships can beestablished by embedding the filter component 601 in the rule based datastructuring system 204 and the data structure grouping and mergingsystem 205. Embedding the filter component 601 with the fieldsubcomponent 402 of the rule based data structuring system 204 and/orthe group series subcomponent 502 of the data structure grouping andmerging system 205 results in associated custom data structures, definedby the rule based data structuring system 204, and/or merged datastructures, defined by the data structure grouping and merging system205, being filtered by the data filtering system 205.

Referring to FIG. 7, this block diagram illustrates an embodiment of acomponent and various methods and the interaction between an embodimentof a series table system 207 within an embodiment of the architectureand framework 202 of FIG. 2. The series table system 207 acts as thein-memory data storage layer that stores all of the series tablecomponents 701 for every series component 402 and group seriessubcomponent 502 in the application. The series table system 207 allowsdevelopers to data bind to common IDE controls, and also to export aseries table component 701 to a database or a data file. The seriestable system 207 is where the incoming device data is stored in memory.The rule-based data structuring system 204 defines how a particularseries table component 701 is defined. The series table system 207 usesthe rule-based data structuring system 204 series components 401 andsubcomponents 402 to form the rows and columns of the in-memory table.As new data is transmitted to a particular series component 401 therelated series table component 701 will store the structured data rowafter it has been processed by the data structuring system and (ifneeded) the data filtering system. The series table system 207automatically performs behind-the-scenes data type conversions for thedeveloper.

The series table system 207 can include a plurality of series tablecomponents 701. Series table components 701 consist of columns and rows.A series component 401 and its corresponding field subcomponents 402 inthe rule-based data structuring system 204 define the actual structurefor a particular series table component 701. The series table component701 allows developers to manage sensor device data in the form of tableand allows them to export and dynamically created databases based off ofthese structures. The series table component 701 allows developers todata source and data bind a particular series component's 401 data or aparticular group series subcomponent's 502 data within the application.

The series table system 207 can include all of the series tablecomponents 701 that are related to series components 401 within acentral device component 202. The series table component 701 isrepresentative of the in-memory data storage layer for each seriescomponent 401 within a central device component 202. The series tablecomponent 701 is defined by the series component 401/group seriessubcomponent 502 properties. Basically, the series table component 701provides developers a way to access data related to a particular seriescomponent 401/group series subcomponent 502 within the application forprogramming/exportation purposes.

As an example, assume a sensor is collecting data and sending data tothe application via the object-oriented wrapping system 203. Once thedata is structured, processed, and filtered (via the data structuringsystem 204, data filtering system 206, and/or data grouping and mergingsystem 205), it is sent to the series table system 207 for storage. Theseries table component 701 automatically creates the in-memory table inwhich a series component's 401/ group series subcomponent's 502 data isstored. The series table component 701 creates the table based off thedeveloper defined properties specified in the series components 401 andcorresponding field subcomponents 402. The series table component 701automatically converts data into the proper data type, and thenpopulates the table with a row of data The series table component 701can then be referenced by the developer for data binding and datasourcing to common controls (i.e. datagridview), or it can be referencedby the data device writer system 208 for automatic exportation to adeveloper defined data base table or data file. The series table systemcan also automatically send data to the data structuring system 204 ifanother series component 401 is related to the series component 401 thatjust sent the data to the series table system 207. Basically, the seriestable system 207 is the data storage layer that provides developers witha way to access series component 401/group series subcomponent 502 data.

In an exemplary embodiment, the series table system 207 can comprises anin-memory data storage layer for each custom data structure, and thecustom data structure can be exported via the table series system to adatabase and/or a data file via the establishment of the aforesaiduser-defined relationships. The in-memory data storage layer can furthercomprise an in-memory data storage layer for each series component 401of the rule based 204 data structuring system. The user can define amaximum number of rows for each the in-memory data storage layer, anduser-defined rules establish management of incoming data after themaximum number of rows has been exceeded.

The series table system 207 can include means (object oriented code) fordata binding and/or data sourcing to common IDE controls and/or visualinterfaces. The user-defined relationships enable the data bindingand/or data sourcing the custom data structures to common IDE controlsand/or visual interfaces. The data sourcing and/or the data binding canbe performed via the establishment of the aforesaid user-definedrelationships among the series table system 207, the rule based datastructuring system 204 and/or the data device writer system 208. In anexemplary embodiment, the user-defined relationships are establishedbetween the series table component 701 of the series table system 207and each of the series component 401 of the rule based 204 datastructuring system and the device writer component 801 of the datadevice writer system 208.

Referring to FIG. 8, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a data device writer system 208 within an embodiment ofthe architecture and framework 202 of FIG. 2. The data device writersystem 208 allows developers to automatically create databases tableand/or data files based off of a series component's or group seriessubcomponent's related series table component 701. The data devicewriter system 208 enables developers to automatically create databasesin common formats and to also automatically insert data into thesecreated databases. The data device writer system 208 enables developersto automatically create data files in common formats and to alsoautomatically insert data into these created data files.

The data device writer system 208 can include a device writer component801. The device writer component 801 allows developers to specify aconnection string or to specify connection parameters that automaticallygenerate the connections string. The data device writer system 208directly interacts with a series table component 701 within a seriestable system 701 (whether it is a group series subcomponent's relatedseries table component 701 or a series component's related series tablecomponent 701).

The data device writer system 208 performs all the behind the scenescreation and insertion functions that need to take place in order toexport a series table component 701 into a database table or a datafile. Based on a few developer defined properties, the data devicewriter component 801 automatically populates a database table/data filewith a row of data every time the related series table component 701 ispopulated with a row of data The data device writer component 801automatically sets the default provider, creates the connections string,connects to the database/data file, checks is the database table/datafile exists, creates the database table/database file if it doesn'texist, maps the series table component data types to the specifieddatabase/data file format, and then builds and adds a row of data to thedata base table/data file.

As an example, assume a sensor is collecting and sending data to theapplication (via the object-oriented wrapping system 203, datastructuring system 204, data filtering system 206) and storing the data(via the series table system 207). The developer wants to automaticallycreate a database table and insert data based off of a series tablecomponent 701 (i.e. every time the series table component 701 gets arow, the database table gets a row of the exact same data inserted intothe created database table). The data device writer system 208automatically interacts with the developer defined database byconnecting to the database, using automatically generated connectionstrings, automatically provided provider drivers, and by mapping thedata types between the series table component 701 and the databasetable. Therefore, just by defining a few properties, the developer canautomatically insert data into a database just by enabling a data devicewriter component 801. The data device writer system 208 provides anautomated way to create and insert data into databases and data fileswhere the data can be further manipulated by applications programming orother applications.

In an exemplary embodiment, the data device writer system 208 caninclude user-defined relationship established between the device writercomponent 801 thereof and the series table component 701 of the seriestable system 207. This enables the data device writer system 208 topopulate common database tables and/or common data files with a row ofdata responsive to the series table component 701 being populated with arow of data. By virtue of user defined relationships, the data devicewriter system 208 can automatically interact with a user-defineddatabase by connecting to the database using at least one ofautomatically generated connection strings and automatically providedprovider drivers, and by mapping the data types between the series tablecomponent 701 and the device writer component 801.

Additionally, the user-defined relationship can be established betweenthe device writer component 801 and at least the series component 401 ofthe rule based data structuring system 204, such that common databasesand/or common data files can be automatically populated based uponevents subscribed to by at least the series component 401.

Referring to FIG. 9, this block diagram illustrates the variouscomponents, subcomponents, and methods and the interaction between anembodiment of a network communications system 209 within an embodimentof the architecture and framework 202 of FIG. 2. The networkcommunications system 209 allows developers to automatically send dataacross a WAN/LAN from the series component's or group seriessubcomponent's related series table component 702 to other like systeminstances. The network communications system 209 enables developers tosend and receive data across using different IP protocols includingTCP/IP and UDP protocols in IPv4, IPv6, and other standards.

The network communications system 209 can include a data sendingcomponent 901 and/or a data receiving component 902. The data sendingcomponent 901 and a data receiving component 902 allows developers tospecify a network address, port, and packet size to allow easycommunication between multiple systems. The data sending component 901directly interacts with a series table component 701 within a seriestable system 207 (whether it be a group series subcomponent's 502related series table component 701 or a series component's 401 relatedseries table component 701) and can send data to a data receivingcomponent 902 when manually called upon to do so or automatically bysubscribing to internal events from the series table component 702. Thedata receiving component 902 can be set to a listening state and awaitdata packets from the data sending component 901. Upon receiving data,the data receiving component 902 can automatically forward the data onto a specified rule-based data structuring system 401 where the data canbe utilized.

As an example, assume a sensor has an application (created via thearchitecture and framework 103) running at-point on the sensor'soperating system. The sensor collects and receives data and transmitsprocessed data to another sensor with the same application runningat-point on its operating system, which then transmits its processeddata to central command station. The network communications system 209can automatically “packetize” a specific series table component's datain such way that it can directly communicate with other sensors/devicesthat are running the application on their respective operating systemswithout having to continually wrap the functions to interact with thesensor. The network communications system 209, based on a few developer(user) defined properties, can automatically convert a series tablecomponent's 701 data into TCP/IP or UDP data packets for use by variousdevices (i.e. other sensors running the application, the internet, anintranet, a central command station, etc.). The data sending component901 would automatically “packetize” the data that needs to betransferred based on the developer defined properties. The datareceiving component 902 would automatically allow for the communicationof sensor data to other sensors running the application (using thepresent invention)—bypassing the object-oriented wrapping system 203,and inserting the sensor data directly into the data structuring system204. The network communications system 209 provides numerous ways inwhich sensor data can be transmitted, and exponential ways in whichsensor data can be implemented on any device that can receive TCP/IPand/or UDP packets.

In an exemplary embodiment, the network communications system 209 caninclude user-defined relationship established between the data sendingcomponent 901 and/or the data receiving component 902 thereof, and atleast the series table component 701 of the series table system 207.Data associated with the series table component 701 can be automaticallypacketized into a format acceptable to devices which send or receivesuch data. In an exemplary embodiment, the user-defined relationship canbe established between the data sending component 901, and/or the datareceiving component 902, and the series component 401 of the rule baseddata structuring system 204.

The custom data structures, or portions thereof, as defined by theseries table system 207, can also be transferred and received based uponan event subscription and/or manually invoked function calls. In anexemplary embodiment, the sending and/or receiving of packetized data isbased upon an event subscription by subscribing series components 401,subscribing field subcomponents 402. The packetized data can be sent andreceived over WAN/LAN networks using network protocols, wherein thenetwork protocols can include TCP/IP and UDP. The network protocols cansupport at least one of IPv4, IPv6, and like standards.

While various embodiments of the present invention have been describedherein, it is to be understood that such embodiments have been presentedby way of example only, and not limitation. It will be apparent topersons skilled in the relevant art(s) that various changes in form anddetail may be made therein without departing from the spirit and scopeof the present invention. This is especially true in light of technologyand terms within the relevant art(s) that may be later developed. Thus,the present invention should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the scope of the associated claims and any equivalents.

1. A reconfigurable hierarchical component based architecture andframework for rapidly developing sensor device enabling softwareapplications comprising: a. a rule-based data structuring system havingat least one of a series component and an associated field subcomponent;b. a series table system having a series table component; c. a system ofacquiring data from a data provider, said data comprised of at leastsensor data; and d. wherein said rule-based data structuring system isconfigured by user-defined relationships to exchange data with at leastone of: i. another rule-based data structuring system, ii. said systemof acquiring data, iii. said series table system, iv. an object orientedwrapping system having at least one of a command component and anassociated parameter subcomponent, and v. a data filtering system havingat least one of a filter component and an associated conditionsubcomponent.
 2. The reconfigurable hierarchical component basedarchitecture and framework of claim 1 wherein said user-definedrelationships are established by at least one of: a. embeddingcomponents of such listed systems within said rulebased data structuringsystem; and b. setting a single property value to link components ofsuch listed systems with said series component of said rule-based datastructuring system.
 3. The reconfigurable hierarchical component basedarchitecture and framework of claim 2 wherein said associated field,parameter and condition subcomponents are user-defined and are one ofembedded or linked in combination with a respective associated componentthereof to establish said user defined relationships.
 4. Thereconfigurable hierarchical component based architecture and frameworkof claim 2 further comprising said rule-based data structuring systemconfigured according to said user-defined relationships to exchange datawith at least one of: a. a data structure grouping and merging systemhaving a sensor group component and at least one of an associated groupseries subcomponent, an associated existing field subcomponent, and anassociated trigger subcomponent; b. a data device writer system havingan associated device writer component; and c. a network communicationssystem having at least one of a data sending component and a datareceiving component.
 5. The reconfigurable hierarchical component basedarchitecture and framework of claim 4 wherein said group series,existing field, and trigger subcomponents are user-defined and are oneof embedded or linked in combination with a respective associatedcomponent thereof to establish said user defined relationships.
 6. Thereconfigurable hierarchical component based architecture and frameworkof claim 4 further comprising said user defined relationshipsestablished between at least two of said system of acquiring data, saidseries table system, said object oriented wrapping system, said datafiltering system, said data structure grouping and merging system, saiddata device writer system, and said network communications system toexchange data therebetween, in addition to exchanging data with saidrule-based data structuring system.
 7. The reconfigurable hierarchicalcomponent based architecture and framework of claim 6 furthercomprising: a. at least one central device component comprised of atleast one of: i. said rule-based data structuring system, ii. saidsystem of acquiring data, iii. said series table system, iv. said objectoriented wrapping system, v. said data filtering system, vi. said datastructure grouping and merging system, vii. said data device writersystem, and viii. said network communications system; and b. whereinsaid central device component is a logical representation of said dataprovider.
 8. The reconfigurable hierarchical component basedarchitecture and framework of claim 7 further comprising a plurality ofinstances of said central device components each usable at the sametime.
 9. The reconfigurable hierarchical component based architectureand framework of claim 7 further comprising: a. an object orienteddesign component toolset having object template derivation tools foraccessing and editing a set of based object templates, such that saidtoolset utilizes inheritance of basic operational capability from acomponent base class existing within an internal framework of an IDE inwhich the reconfigurable hierarchical component based architecture andframework resides; and b. said toolset enabling establishment of saiduser-defined relationships between systems which comprise said centraldevice component.
 10. The reconfigurable hierarchical component basedarchitecture and framework of claim 9 wherein said central devicecomponent further comprises: a. a visual representation thereof; b. adesign-time interface to access said visual representation; c. aprogrammatic interface; and d. a data-binding interface.
 11. Thereconfigurable hierarchical component based architecture and frameworkof claim 10 further comprising establishing said user-definedrelationships by setting said single property value via at least one ofsaid design-time interfaces and said programmatic interfaces.
 12. Thereconfigurable hierarchical component based architecture and frameworkof claim 10 wherein said central device component is saved as a softwareapplication program, said software application program comprised ofcommon object-oriented code, and wherein said software applicationprogram is rapidly developed using a suite of said components andsubcomponents of said systems which employ said user-definedrelationships that establish the exchange of data therebetween.
 13. Acomputer readable medium comprising instructions for causing one or morecomputer systems to emulate the system of claim
 10. 14. Thereconfigurable hierarchical component based architecture and frameworkof claim 10 further comprising separate programmatic, design-time, anddata binding interfaces.
 15. The reconfigurable hierarchical componentbased architecture and framework of claim 14 wherein said design timeinterface comprises a graphical environment for establishing saiduser-defined relationships via said setting a single property value. 16.The reconfigurable hierarchical component based architecture andframework of claim of claim 15 wherein setting said single propertyvalue to link said series component with other components of systems tobe related to said rule base data structuring system further comprisessetting additional property values for said associated subcomponents ofsaid components.
 17. The reconfigurable hierarchical component basedarchitecture and framework of claim 2 wherein said embedding componentsfurther comprises embedding associated subcomponents of said components.18. The reconfigurable hierarchical component based architecture andframework of claim 17 wherein embedding said associated subcomponents isperformed using at least one of said programmatic interface and saiddesign-time interface.
 19. The reconfigurable hierarchical componentbased architecture and framework of claim 1 wherein basic operationalcapability of said components of said systems is inherited from existingcomponent base classes within the internal framework of and IDE in whichsuch systems reside, such that said components said components inheritrespective characteristics and properties from said existing componentbase classes to ensure interface compatibility by taking advantage ofpreviously developed software.
 20. The reconfigurable hierarchicalcomponent based architecture and framework of claim 7 wherein saidobject-oriented wrapping system further comprises: a. means forautomatically generating object-oriented class wrappers of DLL functionsto simplify writing of device enabling programs from at least one ofmanaged and unmanaged DLLs; b. means for modifying wrapped functions ofsaid DLLs; and c. means for relating said wrapped functions to at leastsaid rule-based data structuring system in accord with said user-definedrelationships to exchange data, such that said series table data systemcan be automatically populated with the desired data.
 21. Thereconfigurable hierarchical component based architecture and frameworkof claim 20 further comprising: a. said command component associatedwith said wrapped function b. at least one of a return value and saidparameter subcomponent associated with said command component; c. atleast one wrapped function parameter value associated with said at leastone parameter subcomponent, wherein said at least one wrapped functionparameter value is at least one user defined value for said wrappedfunction; d. said means for modifying said wrapped function comprises ameans for modifying at least one of said return value and said at leastone wrapped function parameter value; and e. said means for relatingsaid wrapped functions comprises a means for establishing saiduser-defined relationships between said command component and saidseries component of said rule based data structuring system.
 22. Thereconfigurable hierarchical component based architecture and frameworkof claim 21 wherein establishing said user-defined relationship furthercomprises: a. setting said single property value to link said seriescomponent with said command component; and b. whereby said fieldsubcomponent is linked to said at least one parameter subcomponentassociated with said command component, and said at least one wrappedfunction parameter value associated with said at least one parametersubcomponent.
 23. The reconfigurable hierarchical component basedarchitecture and framework of claim 21 wherein linking said seriescomponent with said command component further comprises linking saidfield subcomponent with said return value associated with said commandcomponent.
 24. The reconfigurable hierarchical component basedarchitecture and framework of claim 20 wherein code required to wrap thelanguage for each of said wrapped functions is automatically generatedin run-time.
 25. The reconfigurable hierarchical component basedarchitecture and framework of claim 20 further comprising implementinglogic configured to limit acceptable values for said at least oneparameter subcomponent in accordance with acceptable parameter valuesdefined by each of said wrapped functions.
 26. The reconfigurablehierarchical component based architecture and framework of claim 20further comprising empowering logic configured to assign a user-definedname for each of said wrapped functions.
 27. The reconfigurablehierarchical component based architecture and framework of claim 20wherein communication by users with said data provider is enabled. 28.The reconfigurable hierarchical component based architecture andframework of claim 20 wherein said function wrappers are stored inseparate assemblies within memory to eliminate the need for aliasinglike function calls.
 29. The reconfigurable hierarchical component basedarchitecture and framework of claim 20 wherein said wrapped functionsare invoked from said programmatic interface.
 30. The reconfigurablehierarchical component based architecture and framework of claim 20further comprising said wrapped functions having delegate functionalityallowing callbacks of said wrapped functions.
 31. The reconfigurablehierarchical component based architecture and framework of claim 30wherein application references can be specified for said delegatefunction such that callbacks can be initiated in predefined areas of theapplication.
 32. The reconfigurable hierarchical component basedarchitecture and framework of claim 7 wherein said rule-based datastructuring system further comprises: a. at least one of said seriescomponent and said field subcomponent defining a custom data structurefor at least one said data provider associated therewith; and b. atleast one of said series component and said field subcomponent definingthe manner in which data from said at least one associated data providerwill be formatted in said series table system.
 33. The reconfigurablehierarchical component based architecture and framework of claim 32wherein said rule-based data structuring system further comprises atleast one of: a. means for sending data from one rule-based datastructuring system to another rule-based data structuring system; and b.means for receiving data in one rule-based data structuring system sentfrom another rule-based data structuring system.
 34. The reconfigurablehierarchical component based architecture and framework of claim 32wherein said custom data structure is created based upon a previouslycreated custom data structure.
 35. The reconfigurable hierarchicalcomponent based architecture and framework of claim 34 wherein saidcustom data structure further comprises additional fields appended tosaid previously created custom data structure.
 36. The reconfigurablehierarchical component based architecture and framework of claim 32wherein said custom data structure is defined based upon at least one ofsaid return value and said at least one wrapped function parametervalue.
 37. The reconfigurable hierarchical component based architectureand framework of claim 36 wherein said custom data structure is definedbased upon a previously created custom data structure, said custom datastructure further comprising at least one additional field appended tosaid previously created custom data structure, and said at least oneadditional field based upon at least one of said return value and saidat least one wrapped function parameter value.
 38. The reconfigurablehierarchical component based architecture and framework of claim 32wherein events can be fired and subscribed to by subscribing ones of atleast one of said series component and said field subcomponent.
 39. Thereconfigurable hierarchical component based architecture and frameworkof claim 34 wherein said user-defined relationships are establishedbetween a plurality of said custom data structures at least byestablishing said user-defined relationships between said rule baseddata structuring systems.
 40. The reconfigurable hierarchical componentbased architecture and framework of claim 36 wherein relationship linkscan be established between said custom data structure and at least oneof said return value and said at least one wrapped function parametervalue.
 41. The reconfigurable hierarchical component based architectureand framework of claim 32 wherein the said series component and saidfield subcomponent are represented as logical components of at least onedata provider having at least one custom data structure.
 42. Thereconfigurable hierarchical component based architecture and frameworkof claim 32 wherein said series component and said field subcomponentcan be at least one of: i. cloned and serialized for run-timecopy-and-paste functionality of said custom data structure; and ii.copied and pasted in design-time.
 43. The reconfigurable hierarchicalcomponent based architecture and framework of claim 7 wherein saidseries table system further comprises: a. an in-memory data storagelayer for each said custom data structure; and b. said custom datastructure exportable to at least one of a database and a data file viasaid user-defined relationships.
 44. The reconfigurable hierarchicalcomponent based architecture and framework of claim 43 wherein saidin-memory data storage layer further comprises an in-memory data storagelayer for each said series component of said rule-based data structuringsystem.
 45. The reconfigurable hierarchical component based architectureand framework of claim 44 further comprising a user-defined maximumnumber of rows for each said in-memory data storage layer.
 46. Thereconfigurable hierarchical component based architecture and frameworkof claim 45 wherein user-defined rules establish management of incomingdata after said maximum number of rows has been exceeded.
 47. Thereconfigurable hierarchical component based architecture and frameworkof claim 43 said series table system further comprises means for databinding and data sourcing to at least one of common IDE controls andvisual interfaces.
 48. The reconfigurable hierarchical component basedarchitecture and framework of claim 47 wherein said user-definedrelationships enable: a. said data binding of said custom datastructures; and b. said data sourcing of said custom data structures.49. The reconfigurable hierarchical component based architecture andframework of claim 48 wherein at least one of said data sourcing andsaid data binding is performed via establishment of said user-definedrelationships between at least one of said series table system, saidrule based data structuring system, and said data device writer system.50. The reconfigurable hierarchical component based architecture andframework of claim 49 wherein said user-defined relationships areestablished between said series table component and each of said seriescomponent of said rule-based data structuring system and said devicewriter component of said data device writer system.
 51. Thereconfigurable hierarchical component based architecture and frameworkof claim 7 wherein said data filtering system comprises: a. a userdefined expression to filter data, said data defined by said userdefined relationships established between said data filtering system andat least one of said rule based data structuring system and said datastructure grouping and merging system; and b. wherein said user-definedexpression is at least one of a user-defined bitwise operational filtercondition and a user defined common conditional operator.
 52. Thereconfigurable hierarchical component based architecture and frameworkof claim 51 wherein said user defined relationships comprise embeddingsaid filter component in at least one of said rule based datastructuring system and said data structure grouping and merging system.53. The reconfigurable hierarchical component based architecture andframework of claim 52 wherein: a. said filter component is related to atleast one of said field subcomponent of said rule based data structuringsystem and said group series subcomponent of said data structuregrouping and merging system; and b. such that user defined filtering isprovided for at least one of said custom data structures defined by saidrule based data structuring system, and merged data structures definedby said data structure grouping and merging system.
 54. Thereconfigurable hierarchical component based architecture and frameworkof claim 51 wherein said user defined bitwise operational filtercondition comprises at least one of And-ing, NAnd-ing, and Masking. 55.The reconfigurable hierarchical component based architecture andframework of claim 54 wherein said user defined common conditionaloperators comprises at least one of <, >, =, contains, left-mostcontains, and right-most contains.
 56. The reconfigurable hierarchicalcomponent based architecture and framework of claim 55 wherein NOToperations are applied to said user defined common conditionaloperators.
 57. The reconfigurable hierarchical component basedarchitecture and framework of claim 7 wherein said data grouping andmerging system further comprises: a. at least one of said sensor groupcomponent, said group series component, and said existing fieldsubcomponent defining a merged data structure comprised of at least aportion of at least one custom data structure defined by said rule baseddata structuring system; and b. at least one of said sensor groupcomponent, said group series component, and said existing fieldsubcomponent defining the manner in which said merged data structure isformatted in said series table system.
 58. The reconfigurablehierarchical component based architecture and framework of claim 57wherein said user-defined relationship is established between saidsensor group component and at least said series component of said rulebased data structuring system to define said merged data structure. 59.The reconfigurable hierarchical component based architecture andframework of claim 58 wherein said user-defined relationship isestablished by embedding at least said field subcomponent of said rulebased data structuring system in said existing field subcomponent ofsaid data structure merging and grouping system.
 60. The reconfigurablehierarchical component based architecture and framework of claim 58further comprising said merged data structure defined based upon anevent subscription by subscribing ones of at least one of said seriescomponent and said field subcomponent.
 61. The reconfigurablehierarchical component based architecture and framework of claim 60further comprising: a. a trigger subcomponent associated with saidseries component via said sensor group component; and b. said groupseries component having said user-defined relationship established withsaid rule-based data structuring system via at least said subscribingseries component.
 62. The reconfigurable hierarchical component basedarchitecture and framework of claim 58 wherein said merged datastructure is defined based upon common primary keys.
 63. Thereconfigurable hierarchical component based architecture and frameworkof claim 58 wherein a plurality of said merged data structures aregrouped based upon group function calls.
 64. The reconfigurablehierarchical component based architecture and framework of claim 7wherein said data device writer system further comprises: a. saiduser-defined relationship established between said device writercomponent and said series table component; b. said data device writersystem populating at least one of common database tables and common datafiles with a row of data responsive to said series table component beingpopulated with a row of data.
 65. The reconfigurable hierarchicalcomponent based architecture and framework of claim 64 wherein said datadevice writer system automatically interacts with a user-defineddatabase by connecting to said database using at least one ofautomatically generated connection strings and automatically providedprovider drivers, and by mapping the data types between said seriestable component and said device writer component.
 66. The reconfigurablehierarchical component based architecture and framework of claim 65wherein the data device writer further comprises: a. said user-definedrelationship established between said device writer component and atleast said series component of said rule based data structuring system;and b. at least one of said common databases and said common data filesautomatically populated based upon events subscribed to by at least saidseries component.
 67. The reconfigurable hierarchical component basedarchitecture and framework of claim 65 wherein at least one of saidcommon database table and said common data file are populated based uponinvoked bulk insertion functions.
 68. The reconfigurable hierarchicalcomponent based architecture and framework of claim 7 wherein saidnetwork communications system further comprises: a. said user-definedrelationship established between at least one of said data sendingcomponent and said data receiving component and at least said seriestable component of said series table system; and b. data associated withsaid series table component is automatically packetized into a formatacceptable to devices which send or receive such data.
 69. Thereconfigurable hierarchical component based architecture and frameworkof claim 68 wherein said custom data structures, or portions thereof, asdefined by said series table system, are at least one of sent andreceived based upon at least one of an event subscription and manuallyinvoked function calls.
 70. The reconfigurable hierarchical componentbased architecture and framework of claim 69 further comprising: a. saiduser-defined relationship established between at least one of said datasending component and said data receiving component and said seriescomponent of said rule based data structuring system; and b. at leastone of sending and receiving said packetized data is based upon an eventsubscription by at least one of subscribing series components andsubscribing field subcomponents of said rule based data structuringsystem.
 71. The reconfigurable hierarchical component based architectureand framework of claim 68 wherein said packetized data is at least oneof sent and received over WAN/LAN networks using network protocols, andwherein said network protocols are at least one of TCP/IP and UDP. 72.The reconfigurable hierarchical component based architecture andframework of claim 71 wherein said network protocols support at leastone of IPv4, IPv6, and like standards.
 73. A method for rapidlydeveloping sensor device enabling software applications, said methodcomprising: a. defining a rule-based data structuring system having aseries component and a field subcomponent; b. defining a series tablesystem having a series table component; c. receiving sensor data intosaid rule-based data structuring system; and d. defining relationshipsto exchange data between said rule-based data structuring system and atleast one of: i. another rule-based data structuring system; ii. saidsystem of acquiring data; iii. said series table system; iv. an objectoriented wrapping system having a command component and a parametersubcomponent; and v. a data filtering system having a filter componentand a condition subcomponent.
 74. The method of claim 73 furthercomprising establishing said relationships by at least one of: a.embedding components of such listed systems within said rulebased datastructuring system; and b. setting a single property value to linkcomponents of such listed systems with said series component of saidrule-based data structuring system.
 75. The method of claim 74 whereinsaid associated field, parameter and condition subcomponents areuser-defined and are one of embedded or linked in combination with arespective associated component thereof to establish said user definedrelationships.
 76. The method of claim 74 further comprisingestablishing said user defined relationships to exchange data betweensaid rule-based data structuring system and at least one of: a. a datastructure grouping and merging system having at least one of a sensorgroup component, a group series subcomponent, an existing fieldsubcomponent, and a trigger subcomponent, b. a data device writer systemhaving a device writer component, and c. a network communications systemhaving at least one of a data sending component and a data receivingcomponent.
 77. The method of claim 76 further comprising establishingsaid user defined relationships between said group series, existingfield, and trigger subcomponents by one of embedding or linking incombination with a respective associated component thereof.
 78. Themethod claim 74 further comprising establishing said user definedrelationships to exchange data between at least two of: said system ofacquiring data, said series table system, said object oriented wrappingsystem, said data filtering system, said data structure grouping andmerging system, said data device writer system, and said networkcommunications system.
 79. The method claim 78 further comprising: a.representing at least one of said rule-based data structuring system,said system of acquiring data, said series table system, said objectoriented wrapping system, said data filtering system, said datastructure grouping and merging system, said data device writer system,and said network communications system as a central device component;and b. wherein said at least one central device component is a logicalrepresentation of a device which provides data to be processed by saidmethod.
 80. The method of claim 79 further comprising creating aplurality of instances of said central device components, each usable atthe same time.
 81. The method claim 79 further comprising: a.implementing an object design component toolset for providing objecttemplate derivation tools for accessing and editing a set of basedobject templates, wherein said toolset inherits basic operationalcapability from a component base class existing within an internalframework of an IDE in which the toolset resides; b. establishing saiduser-defined relationships between systems which comprise said centraldevice component using said toolset; and c. implementing a reusablesoftware component encapsulating functionality wherein multipleinstances of a component are usable at the same time.
 82. The methodclaim 81 further comprising: a. providing a visual representation ofsaid central device component; b. providing a design-time interface toaccess said visual representation; c. providing a programmatic interfacefor said central device component; and d. a data-binding interface forsaid central device component.
 83. The method of claim 82 furthercomprising establishing said user-defined relationships by setting saidsingle property value via at least one of said design-time interface andsaid programmatic interface.
 84. The method of claim 82 furthercomprising saving said central device component as a softwareapplication program comprised of common object-oriented code, whereinsaid software application program is rapidly developed using a suite ofsaid components and subcomponents of said systems which employ saiduser-defined relationships that establish the exchange of datatherebetween.
 85. A computer readable medium comprising instructions forcausing one or more computer systems to implement the method of claim82.
 86. The method of claim 73 further comprising providing separatedprogrammatic, design-time, and data binding interfaces.
 87. The methodof claim 86 wherein providing said design time interfaces furthercomprises providing a graphical environment for establishing saiduser-defined relationships via said setting a single property value. 88.The method of claim of claim 87 wherein setting said single propertyvalue further comprises setting additional property values forassociated subcomponents of said components.
 89. The method of claim 74wherein said embedding components further comprises embedding associatedsubcomponents of said components.
 90. The method of claim 89 whereinembedding said associated subcomponents is performed using at least oneof said programmatic interface, said data-binding interface, and saiddesign-time interface.
 91. The method of claim 73 wherein basicoperational capability of said components of said systems is inheritedfrom existing component base classes within the internal framework ofand IDE in which such systems reside, such that said components inheritrespective characteristics and properties from said existing componentbase classes to ensure interface compatibility by taking advantage ofpreviously developed software.
 92. The method of claim 79 wherein saidobject-oriented wrapping system further comprises: a. automaticallygenerating object-oriented class wrappers of DLL functions to simplifywriting of device enabling programs from at least one of managed andunmanaged DLLs; b. modifying wrapped functions of said DLLs; and c.relating said wrapped functions to at least said rule-based datastructuring system in accord with said user-defined relationships toexchange data, such that said series table data system can beautomatically populated with the desired data.
 93. The method of claim92 wherein said object-oriented wrapping system further comprises: a.associating said command component with said wrapped function; b.associating at least one of a return value and said parametersubcomponent with said command component; c. associating at least onewrapped function parameter value with said at least one parametersubcomponent, wherein said at least one wrapped function parameter valueis at least one user defined value for said wrapped function; d.modifying said wrapped function by modifying at least one of saidwrapped function parameter value and said return value; and e. relatingsaid wrapped functions by establishing said user-defined relationshipsbetween said command component and said series component of said rulebased data structuring system.
 94. The method of claim 93 whereinestablishing said user-defined relationship further comprises: a.setting said single property value to link said series component withsaid command component; and b. whereby said field subcomponent is linkedto said at least one parameter subcomponent associated with said commandcomponent and said at least one wrapped function parameter valueassociated with said at least one parameter subcomponent.
 95. The methodof claim 93 wherein said user-defined relationship comprises settingsaid single property value to link at least one of said return value andsaid at least one parameter subcomponent with at least one of saidseries component and said associated field subcomponent of saidrule-based data structuring system.
 96. The method of claim 92 furthercomprising automatically generating in run-time the code required towrap the language for each of said wrapped functions.
 97. The method ofclaim 92 further comprising limiting acceptable values for said at leastone parameter subcomponent in accordance with acceptable parametervalues defined by each of said wrapped functions.
 98. The method ofclaim 92 further comprising assigning a user-defined name for each ofsaid wrapped functions.
 99. The method of claim 92 further comprisingenabling users to communicate with a device providing data processed bysaid method.
 100. The method of claim 92 further comprising storing saidfunction wrappers in separate assemblies within memory to eliminate theneed for aliasing like function calls.
 101. The method of claim 92further comprising invoking said wrapped function and at least one ofsaid return value and said at least one parameter subcomponent from saiddesign-time interface.
 102. The method of claim 92 further comprisingproviding delegate functionality for said wrapped functions to allowcallbacks of said wrapped functions.
 103. The method of claim 102further comprising specifying application references for said delegatefunction to initiate callbacks from predefined areas.
 104. The method ofclaim 79 further comprising said rule-based data structuring system: a.defining a custom data structure based upon at least one of said seriescomponent and said field subcomponent for associated sensor datareceived from at least one source of said sensor data; and b. saidseries component and said field subcomponent defining the manner inwhich said associated sensor data is formatted in said series tablesystem;
 105. The method of claim 104 further comprising at least one of:a. sending data from one rule-based data structuring system to anotherrule-based data structuring system; and b. receiving data in onerule-based data structuring system sent from another rule-based datastructuring system.
 106. The method of claim 104 further comprisingdefining said custom data structure based upon a previously createdcustom data structure.
 107. The method of claim 106 further comprisingappending additional fields from a previously created custom datastructure to said custom data structure.
 108. The method of claim 104further comprising defining said custom data structure based upon atleast one of said return values and said at least one parametersubcomponent of said wrapped function.
 109. The method of claim 108further comprising: a. defining said custom data structure based upon apreviously created custom data structure; b. wherein at least oneadditional field is appended to said previously created custom datastructure to create said custom data structure; and c. defining said atleast one additional field based upon at least one of said return valueand said at least one parameter subcomponent of said wrapped function.110. The method of claim 104 further comprising subscribing to andfiring events via at least one of a subscribing series component and asubscribing field subcomponent.
 111. The method of claim 106 furthercomprising establishing user-defined relationships between a pluralityof said custom data structures by establishing said user-definedrelationships between said rule based data structuring systems.
 112. Themethod of claim 108 further comprising establishing relationship linksbetween said custom data structure and at least one of said parametersubcomponents and said return value of said wrapped function.
 113. Themethod of claim 104 further comprising representing said seriescomponent and said field subcomponent as logical components of at leastone source of sensor data having at least one associated custom datastructure.
 114. The method of claim 104 further comprising at least oneof cloning and serializing at least one of said series component andsaid field subcomponent to enable run-time copy-and-paste functionalityof said custom data structure.
 115. The method of claim 79 furthercomprising said series table system: a. providing an in-memory datastorage layer for each said custom data structure; and b. exporting saidcustom data structure to at least one of a database and a data file viasaid user-defined relationships.
 116. The method of claim 115 whereinsaid in-memory data storage layer further comprises an in-memory datastorage layer for each said series component of said rule-based datastructuring system.
 117. The method of claim 116 further comprisingdefining a maximum number of rows for each said in-memory data storagelayer.
 118. The method of claim 117 further comprising user-definedrules establishing management of incoming data after said maximum numberof rows has been exceeded.
 119. The method of claim 115 furthercomprising at least one of data binding and data sourcing said customdata structures to at least one of common IDE controls and visualinterfaces.
 120. The method of claim 119 wherein at least one of saiddata sourcing and said data binding is enabled by establishing said userdefined relationships.
 121. The method of claim 120 wherein at least oneof said data sourcing and said data binding is responsive to saiduser-defined relationships established between at least one of saidseries table system, said rule based data structuring system and saiddata device writer system.
 122. The method of claim 121 furthercomprising establishing said user-defined relationships between saidseries table component and each of said series component of saidrule-based data structuring system and said device writer component ofsaid data device writer system.
 123. The method of claim 79 wherein saiddata filtering system: a. filtering data based upon a user definedexpression, said data defined by said user defined relationshipsestablished between said data filtering system and at least one of saidrule based data structuring system and said data structure grouping andmerging system; and b. wherein said user-defined expression is at leastone of a user defined bitwise operational filter condition and a userdefined common conditional operator.
 124. The method of claim 123further comprising embedding said filter component in at least one ofsaid rule based data structuring system and said data structure groupingand merging system.
 125. The method of claim 124 further comprising: a.relating said filter component to at least one of said fieldsubcomponent of said rule based data structuring system and said groupseries subcomponent of said data structure grouping and merging system;and b. such that user defined filtering is provided for at least one ofsaid custom data structures defined by said rule based data structuringsystem, and merged data structures defined by said data structuregrouping and merging system.
 126. The method of claim 123 wherein saiduser defined bitwise operational filter condition comprises at least oneof And-ing, NAnd-ing, and Masking.
 127. The method of claim 126 whereinsaid user defined common conditional operators comprises at least one of<, >, =, contains, left-most contains, and right-most contains.
 128. Themethod of claim 127 further comprising applying NOT operations said userdefined common conditional operators.
 129. The method of claim 79further comprising said data grouping and merging system: a. defining amerged data structure based upon at least one of said sensor groupcomponent, said group series component, and said existing fieldsubcomponent, wherein said merged data structure is comprised of atleast a portion of at least one custom data structure defined by saidrule based data structuring system; and b. defining the manner in whichsaid merged data structure is formatted in said series table systembased upon at least one of said sensor group component, said groupseries component, and said existing field subcomponent.
 130. The methodof claim 129 further comprising establishing said user-definedrelationship between said sensor group component and at least saidseries component of said rule based data structuring system to definesaid merged data structure.
 131. The method of claim 130 furthercomprising establishing said user-defined relationship by embedding atleast said field subcomponent of said rule based data structuring systemin said existing field subcomponent of said data structure merging andgrouping system.
 132. The method of claim 130 further comprisingdefining said merged data structure based upon an event subscription bysubscribing ones of at least one of said series component and said fieldsubcomponent.
 133. The method of claim 132 further comprising: a.associating a trigger subcomponent with said series component via saidsensor group component; and b. establishing said user definedrelationship between said group series component said rule-based datastructuring system via at least said subscribing series component. 134.The method of claim 130 further comprising defining said merged datastructure based upon common primary keys.
 135. The method of claim 130further comprising grouping a plurality of said merged data structuresbased upon group function calls.
 136. The method of claim 79 furthercomprising said data device writer: a. populating at least one of commondatabase tables and common data files with a row of data responsive tosaid series table component of said series table system being populatedwith a row of data; and b. said populating based upon establishing saiduser-defined relationships between said device writer component and saidseries table component.
 137. The method of claim 136 further comprisingsaid data device writer system automatically interacting with auser-defined database by connecting to said database using at least oneof automatically generated connection strings and automatically providedprovider drivers, and by mapping the data types between said seriestable component and said device writer component.
 138. The method ofclaim 137 further comprising: a. establishing said user-definedrelationship between said device writer component and at least saidseries component of said rule based data structuring system; and b.automatically populating at least one of said common databases and saidcommon data files based upon events subscribed to by subscribing ones ofat least one of said series component and said field subcomponentthereof.
 139. The method of claims 137 further comprising populating atleast one of said common database table and said common data file basedupon invoked bulk insertion functions.
 140. The method of claim 79further comprising said network communications system: a. establishingsaid user-defined relationship between at least one of said data sendingcomponent and said data receiving component and at least said seriestable component of said series table system; b. automaticallypacketizing data associated with said series table component into aformat acceptable to devices which send or receive such data; and c. atleast one of sending and receiving packetized data between at least oneof multiple data structures and other devices which send or receive suchdata.
 141. The method of claim 140 further comprising at least one ofsending and receiving said custom data structures, or portions thereof,as defined by said series table system, based upon at least one of anevent subscription and manually invoked function calls.
 142. The methodof claim 141 further comprising: a. establishing said user-definedrelationships between at least one of said data sending component andsaid data receiving component and said series component of said rulebased data structuring system; and b. at least one of sending andreceiving packetized data based upon an event subscription bysubscribing ones of at least one of said series components, said fieldsubcomponents.
 143. The method of claim 140 further comprising at leastone of sending and receiving packetized data over WAN/LAN networks usingnetwork protocols, and wherein said network protocols are at least oneof TCP/IP and UDP.
 144. The method of claim 143 wherein said networkprotocols support at least one of IPv4, IPv6, and like standards.